diff options
| -rw-r--r-- | README.mediawiki | 6 | ||||
| -rw-r--r-- | bip-0065.mediawiki (renamed from bip-checklocktimeverify.mediawiki) | 34 |
2 files changed, 23 insertions, 17 deletions
diff --git a/README.mediawiki b/README.mediawiki index ea9783a..8ad9e17 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -236,6 +236,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Standard | Draft |- +| [[bip-0065.mediawiki|65]] +| OP_CHECKLOCKTIMEVERIFY +| Peter Todd +| Standard +| Draft +|- | [[bip-0070.mediawiki|70]] | Payment protocol | Gavin Andresen diff --git a/bip-checklocktimeverify.mediawiki b/bip-0065.mediawiki index ee88c51..9574374 100644 --- a/bip-checklocktimeverify.mediawiki +++ b/bip-0065.mediawiki @@ -1,5 +1,5 @@ <pre> - BIP: + BIP: 65 Title: OP_CHECKLOCKTIMEVERIFY Author: Peter Todd <pete@petertodd.org> Status: Draft @@ -85,13 +85,13 @@ funds with the following scriptSig: ===Non-interactive time-locked refunds=== There exist a number of protocols where a transaction output is created that -the co-operation of both parties to spend the output. To ensure the failure of -one party does not result in the funds becoming lost refund transactions are -setup in advance using nLockTime. These refund transactions need to be created -interactively, and additionaly, are currently vulnerable to transaction -mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the -interactive setup with a non-interactive setup, and additionally, making -transaction mutability a non-issue. +requires the co-operation of both parties to spend the output. To ensure the +failure of one party does not result in the funds becoming lost refund +transactions are setup in advance using nLockTime. These refund transactions +need to be created interactively, and additionaly, are currently vulnerable to +transaction mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, +replacing the interactive setup with a non-interactive setup, and additionally, +making transaction mutability a non-issue. ====Two-factor wallets==== @@ -193,13 +193,13 @@ semantics and detailed rationale for those semantics. // CHECKLOCKTIMEVERIFY // // (nLockTime -- nLockTime ) - + if (!(flags & SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY)) break; // not enabled; treat as a NOP - + if (stack.size() < 1) return false; - + // Note that elsewhere numeric opcodes are limited to // operands in the range -2**31+1 to 2**31-1, however it is // legal for opcodes to produce results exceeding that @@ -215,13 +215,13 @@ semantics and detailed rationale for those semantics. // to 5-byte bignums, which are good until 2**32-1, the // same limit as the nLockTime field itself. const CScriptNum nLockTime(stacktop(-1), 5); - + // In the rare event that the argument may be < 0 due to // some arithmetic being done first, you can always use // 0 MAX CHECKLOCKTIMEVERIFY. if (nLockTime < 0) return false; - + // There are two times of nLockTime: lock-by-blockheight // and lock-by-blocktime, distinguished by whether // nLockTime < LOCKTIME_THRESHOLD. @@ -234,12 +234,12 @@ semantics and detailed rationale for those semantics. (txTo.nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD) )) return false; - + // Now that we know we're comparing apples-to-apples, the // comparison is a simple numeric one. if (nLockTime > (int64_t)txTo.nLockTime) return false; - + // Finally the nLockTime feature can be disabled and thus // CHECKLOCKTIMEVERIFY bypassed if every txin has been // finalized by setting nSequence to maxint. The @@ -252,9 +252,9 @@ semantics and detailed rationale for those semantics. // required to prove correct CHECKLOCKTIMEVERIFY execution. if (txTo.vin[nIn].IsFinal()) return false; - + break; - + } https://github.com/petertodd/bitcoin/commit/ab0f54f38e08ee1e50ff72f801680ee84d0f1bf4 |