BIP65 assigned for CHECKLOCKTIMEVERIFY

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

bip-checklocktimeverify.mediawiki → bip-0065.mediawiki

@@ -1,5 +1,5 @@
 <pre>
-  BIP:
+  BIP: 65
   Title: OP_CHECKLOCKTIMEVERIFY
   Author: Peter Todd <[email protected]>
   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