diff --git a/bip-csv.mediawiki b/bip-0112.mediawiki similarity index 79% rename from bip-csv.mediawiki rename to bip-0112.mediawiki index ead3edb0..c06caf50 100644 --- a/bip-csv.mediawiki +++ b/bip-0112.mediawiki @@ -1,5 +1,5 @@ 
-  BIP: XX
+  BIP: 112
   Title: CHECKSEQUENCEVERIFY
   Authors: BtcDrak 
            Mark Friedenbach 	
@@ -29,7 +29,7 @@ the script fails immediately.
 
 BIP 68's redefinition of nSequence prevents a non-final transaction
 from being selected for inclusion in a block until the corresponding
-input has reached the specified age, as measured in block heiht or
+input has reached the specified age, as measured in block height or
 block time. By comparing the argument to CHECKSEQUENCEVERIFY against
 the nSequence field, we indirectly verify a desired minimum age of the
 the output being spent; until that relative age has been reached any
@@ -58,6 +58,14 @@ Refer to the reference implementation, reproduced below, for the precise
 semantics and detailed rationale for those semantics.
 
     
+    // Threshold for nLockTime: below this value it is interpreted as block number,
+    // otherwise as UNIX timestamp (already defined in Bitcoin Core).
+    static const unsigned int LOCKTIME_THRESHOLD = 500000000; // Tue Nov  5 00:53:20 1985 UTC
+    
+    // Threshold for inverted nSequence: below this value it is interpreted
+    // as a relative lock-time, otherwise ignored.
+    static const uint32_t SEQUENCE_THRESHOLD = (1 << 31);
+    
     case OP_NOP3:
     {
         if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
@@ -107,19 +115,19 @@ semantics and detailed rationale for those semantics.
         // number rules.
         if (txTo->nVersion < 2)
             return false;
-
+        
         // Sequence number must be inverted to convert it into a
         // relative lock-time.
-	txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence;
+        txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence;
         
         // Sequence numbers under SEQUENCE_THRESHOLD are not consensus
-	// constrained.
-	if (txToInvSequence >= SEQUENCE_THRESHOLD)
+        // constrained.
+        if (txToInvSequence >= SEQUENCE_THRESHOLD)
             return false;
         
         // There are two types of relative lock-time: lock-by-
         // blockheight and lock-by-blocktime, distinguished by
-	// whether txToInvSequence < LOCKTIME_THRESHOLD.
+        // whether txToInvSequence < LOCKTIME_THRESHOLD.
         //
         // We want to compare apples to apples, so fail the script
         // unless the type of lock-time being tested is the same as
@@ -132,9 +140,9 @@ semantics and detailed rationale for those semantics.
         
         // Now that we know we're comparing apples-to-apples, the
         // comparison is a simple numeric one.
-        if (nInvSequence > txInvToSequence)
+        if (nInvSequence > txToInvSequence)
             return false;
-    
+        
         return true;
     }
 
@@ -173,13 +181,21 @@ https://github.com/maaku/bitcoin/tree/checksequenceverify
 ==Deployment==
 
 We reuse the double-threshold switchover mechanism from BIPs 34 and
-66, with the same thresholds, but for nVersion = 4. The new rules are
-in effect for every block (at height H) with nVersion = 4 and at least
+66, with the same thresholds, but for nVersion = 8. The new rules are
+in effect for every block (at height H) with nVersion = 8 and at least
 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
-have nVersion = 4. Furthermore, when 950 out of the 1000 blocks
-preceding a block do have nVersion = 4, nVersion = 3 blocks become
+have nVersion = 8. Furthermore, when 950 out of the 1000 blocks
+preceding a block do have nVersion = 8, nVersion = 3 blocks become
 invalid, and all further blocks enforce the new rules.
 
+When assessing the block version as mask of ~0x20000007 must be applied
+to work around the complications caused by
+[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html BIP101's premature use]
+of the [https://gist.github.com/sipa/bf69659f43e763540550 undecided version bits proposal].
+
+By applying ~0x20000007 with nVersion = 8, the thresholds should be tested
+comparing block nVersion >= 4 as this will save a bit for future use.
+
 It is recommended that this soft-fork deployment trigger include other 
 related proposals for improving Bitcoin's lock-time capabilities, including:
 
@@ -189,10 +205,9 @@ OP_CHECKLOCKTIMEVERIFY,
 [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]: 
 Consensus-enforced transaction replacement signalled via sequence numbers,
 
-and [https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki BIP XX]: 
+and [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP 113]: 
 Median-Past-Time-Lock.
 
-
 ==Credits==
 
 Mark Friedenbach invented the application of sequence numbers to
@@ -202,7 +217,7 @@ CHECKSEQUENCEVERIFY.
 The reference implementation and this BIP was based heavily on work
 done by Peter Todd for the closely related BIP 65.
 
-BtcDrak edited this BIP document.
+BtcDrak authored this BIP document.
 
 
 ==References==
@@ -214,13 +229,17 @@ https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
 BIP 65: OP_CHECKLOCKTIMEVERIFY
 https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
 
-BIP XX: Median past block time for time-lock constraints
-https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki
+BIP 113: Median past block time for time-lock constraints
+https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
 
 HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and
 revocation hashes
 http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
 
+[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
+
+[https://gist.github.com/sipa/bf69659f43e763540550 Version bits]
+
 
 ==Copyright==