{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-13\n📝 Original message:As per the rules of BIP 1, I hereby request that the BIP editor please\nassign an official number to this work. The idea has been discussed before\non the bitcoin-dev mailing list:\n\nhttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008452.html\n\nAnd a reference implementation is available here:\n\nhttps://github.com/maaku/bitcoin/tree/checksequenceverify\n\n\nOn Thu, Aug 13, 2015 at 4:06 AM, Btc Drak via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I have written the following draft BIP for a new opcode\n\u003e CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of\n\u003e relative-locktime to Bitcoin's scripting language.\n\u003e\n\u003e\n\u003e https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki\n\u003e\n\u003e \u003cpre\u003e\n\u003e   BIP: XX\n\u003e   Title: CHECKSEQUENCEVERIFY\n\u003e   Authors: BtcDrak \u003cbtcdrak at gmail.com\u003e\n\u003e            Mark Friedenbach \u003cmark at friedenbach.org\u003e\n\u003e   Status: Draft\n\u003e   Type: Standards Track\n\u003e   Created: 2015-08-10\n\u003e \u003c/pre\u003e\n\u003e\n\u003e ==Abstract==\n\u003e\n\u003e This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin\n\u003e scripting system that in combination with BIP 68 allows execution\n\u003e pathways of a script to be restricted based on the age of the output\n\u003e being spent.\n\u003e\n\u003e\n\u003e ==Summary==\n\u003e\n\u003e CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed\n\u003e it compares the top item on the stack to the inverse of the nSequence\n\u003e field of the transaction input containing the scriptSig. If the\n\u003e inverse of nSequence is less than the sequence threshold (1 \u003c\u003c 31),\n\u003e the transaction version is greater than or equal to 2, and the top\n\u003e item on the stack is less than or equal to the inverted nSequence,\n\u003e script evaluation continues as though a NOP was executed. Otherwise\n\u003e the script fails immediately.\n\u003e\n\u003e BIP 68's redefinition of nSequence prevents a non-final transaction\n\u003e from being selected for inclusion in a block until the corresponding\n\u003e input has reached the specified age, as measured in block heiht or\n\u003e block time. By comparing the argument to CHECKSEQUENCEVERIFY against\n\u003e the nSequence field, we indirectly verify a desired minimum age of the\n\u003e the output being spent; until that relative age has been reached any\n\u003e script execution pathway including the CHECKSEQUENCEVERIFY will fail\n\u003e to validate, causing the transaction not to be selected for inclusion\n\u003e in a block.\n\u003e\n\u003e\n\u003e ==Motivation==\n\u003e\n\u003e BIP 68 repurposes the transaction nSequence field meaning by giving\n\u003e sequence numbers new consensus-enforced semantics as a relative\n\u003e lock-time. However, there is no way to build Bitcoin scripts to make\n\u003e decisions based on this field.\n\u003e\n\u003e By making the nSequence field accessible to script, it becomes\n\u003e possible to construct code pathways that only become accessible some\n\u003e minimum time after proof-of-publication. This enables a wide variety\n\u003e of applications in phased protocols such as escrow, payment channels,\n\u003e or bidirectional pegs.\n\u003e\n\u003e\n\u003e ==Specification==\n\u003e\n\u003e Refer to the reference implementation, reproduced below, for the precise\n\u003e semantics and detailed rationale for those semantics.\n\u003e\n\u003e\n\u003e     case OP_NOP3:\n\u003e     {\n\u003e         if (!(flags \u0026 SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {\n\u003e             // not enabled; treat as a NOP3\n\u003e             if (flags \u0026 SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {\n\u003e                 return set_error(serror,\n\u003e SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);\n\u003e             }\n\u003e             break;\n\u003e         }\n\u003e\n\u003e         if (stack.size() \u003c 1)\n\u003e             return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);\n\u003e\n\u003e         // Note that unlike CHECKLOCKTIMEVERIFY we do not need to\n\u003e         // accept 5-byte bignums since any value greater than or\n\u003e         // equal to SEQUENCE_THRESHOLD (= 1 \u003c\u003c 31) will be rejected\n\u003e         // anyway. This limitation just happens to coincide with\n\u003e         // CScriptNum's default 4-byte limit with an explicit sign\n\u003e         // bit.\n\u003e         //\n\u003e         // This means there is a maximum relative lock time of 52\n\u003e         // years, even though the nSequence field in transactions\n\u003e         // themselves is uint32_t and could allow a relative lock\n\u003e         // time of up to 120 years.\n\u003e         const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal);\n\u003e\n\u003e         // In the rare event that the argument may be \u003c 0 due to\n\u003e         // some arithmetic being done first, you can always use\n\u003e         // 0 MAX CHECKSEQUENCEVERIFY.\n\u003e         if (nInvSequence \u003c 0)\n\u003e             return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);\n\u003e\n\u003e         // Actually compare the specified inverse sequence number\n\u003e         // with the input.\n\u003e         if (!CheckSequence(nInvSequence))\n\u003e             return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);\n\u003e\n\u003e         break;\n\u003e     }\n\u003e\n\u003e     bool CheckSequence(const CScriptNum\u0026 nInvSequence) const\n\u003e     {\n\u003e         int64_t txToInvSequence;\n\u003e\n\u003e         // Fail under all circumstances if the transaction's version\n\u003e         // number is not set high enough to enable enforced sequence\n\u003e         // number rules.\n\u003e         if (txTo-\u003enVersion \u003c 2)\n\u003e             return false;\n\u003e\n\u003e         // Sequence number must be inverted to convert it into a\n\u003e         // relative lock-time.\n\u003e         txToInvSequence = (int64_t)~txTo-\u003evin[nIn].nSequence;\n\u003e\n\u003e         // Sequence numbers under SEQUENCE_THRESHOLD are not consensus\n\u003e         // constrained.\n\u003e         if (txToInvSequence \u003e= SEQUENCE_THRESHOLD)\n\u003e             return false;\n\u003e\n\u003e         // There are two types of relative lock-time: lock-by-\n\u003e         // blockheight and lock-by-blocktime, distinguished by\n\u003e         // whether txToInvSequence \u003c LOCKTIME_THRESHOLD.\n\u003e         //\n\u003e         // We want to compare apples to apples, so fail the script\n\u003e         // unless the type of lock-time being tested is the same as\n\u003e         // the lock-time in the transaction input.\n\u003e         if (!(\n\u003e             (txToInvSequence \u003c  LOCKTIME_THRESHOLD \u0026\u0026 nInvSequence \u003c\n\u003e LOCKTIME_THRESHOLD) ||\n\u003e             (txToInvSequence \u003e= LOCKTIME_THRESHOLD \u0026\u0026 nInvSequence \u003e=\n\u003e LOCKTIME_THRESHOLD)\n\u003e         ))\n\u003e             return false;\n\u003e\n\u003e         // Now that we know we're comparing apples-to-apples, the\n\u003e         // comparison is a simple numeric one.\n\u003e         if (nInvSequence \u003e txInvToSequence)\n\u003e             return false;\n\u003e\n\u003e         return true;\n\u003e     }\n\u003e\n\u003e\n\u003e https://github.com/maaku/bitcoin/commit/33be476a60fcc2afbe6be0ca7b93a84209173eb2\n\u003e\n\u003e\n\u003e ==Example: Escrow with Timeout==\n\u003e\n\u003e An escrow that times out automatically 30 days after being funded can be\n\u003e established in the following way. Alice, Bob and Escrow create a 2-of-3\n\u003e address with the following redeemscript.\n\u003e\n\u003e     IF\n\u003e         2 \u003cAlice's pubkey\u003e \u003cBob's pubkey\u003e \u003cEscrow's pubkey\u003e 3\n\u003e CHECKMULTISIGVERIFY\n\u003e     ELSE\n\u003e         \u003cLOCKTIME_THRESHOLD + 30*24*60*60\u003e CHECKSEQUENCEVERIFY DROP\n\u003e         \u003cAlice's pubkey\u003e CHECKSIGVERIFY\n\u003e     ENDIF\n\u003e\n\u003e At any time funds can be spent using signatures from any two of Alice,\n\u003e Bob or the Escrow.\n\u003e\n\u003e After 30 days Alice can sign alone.\n\u003e\n\u003e The clock does not start ticking until the payment to the escrow address\n\u003e confirms.\n\u003e\n\u003e\n\u003e ==Reference Implementation==\n\u003e\n\u003e A reference implementation is provided in the following git repository:\n\u003e\n\u003e https://github.com/maaku/bitcoin/tree/checksequenceverify\n\u003e\n\u003e\n\u003e ==Deployment==\n\u003e\n\u003e We reuse the double-threshold switchover mechanism from BIPs 34 and\n\u003e 66, with the same thresholds, but for nVersion = 4. The new rules are\n\u003e in effect for every block (at height H) with nVersion = 4 and at least\n\u003e 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also\n\u003e have nVersion = 4. Furthermore, when 950 out of the 1000 blocks\n\u003e preceding a block do have nVersion = 4, nVersion = 3 blocks become\n\u003e invalid, and all further blocks enforce the new rules.\n\u003e\n\u003e It is recommended that this soft-fork deployment trigger include other\n\u003e related proposals for improving Bitcoin's lock-time capabilities,\n\u003e including:\n\u003e\n\u003e [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]:\n\u003e OP_CHECKLOCKTIMEVERIFY,\n\u003e\n\u003e [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]:\n\u003e Consensus-enforced transaction replacement signalled via sequence numbers,\n\u003e\n\u003e and [https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki BIP\n\u003e XX]:\n\u003e Median-Past-Time-Lock.\n\u003e\n\u003e\n\u003e ==Credits==\n\u003e\n\u003e Mark Friedenbach invented the application of sequence numbers to\n\u003e achieve relative lock-time, and wrote the reference implementation of\n\u003e CHECKSEQUENCEVERIFY.\n\u003e\n\u003e The reference implementation and this BIP was based heavily on work\n\u003e done by Peter Todd for the closely related BIP 65.\n\u003e\n\u003e BtcDrak authored this BIP document.\n\u003e\n\u003e\n\u003e ==References==\n\u003e\n\u003e BIP 68: Consensus-enforced transaction replacement signalled via\n\u003e sequence numbers\n\u003e https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki\n\u003e\n\u003e BIP 65: OP_CHECKLOCKTIMEVERIFY\n\u003e https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki\n\u003e\n\u003e BIP XX: Median past block time for time-lock constraints\n\u003e https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki\n\u003e\n\u003e HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and\n\u003e revocation hashes\n\u003e\n\u003e http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html\n\u003e\n\u003e\n\u003e ==Copyright==\n\u003e\n\u003e This document is placed in the public domain.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150813/0d50ce22/attachment-0001.html\u003e"}