summaryrefslogtreecommitdiff
path: root/bip-0068.mediawiki
diff options
context:
space:
mode:
authorBtcDrak <btcdrak@gmail.com>2015-11-20 16:50:18 +0000
committerBtcDrak <btcdrak@gmail.com>2015-11-20 18:56:00 +0000
commitc141645a1f6428ba183c927391efb1d316f45743 (patch)
tree36ce3c4cc7da3172d396a0adaaffa4b53508dc34 /bip-0068.mediawiki
parent7d7083f722efa414b9cf3d7c1346d34d53f89b01 (diff)
Update compatibility section
Diffstat (limited to 'bip-0068.mediawiki')
-rw-r--r--bip-0068.mediawiki16
1 files changed, 8 insertions, 8 deletions
diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 44b8a1a..6d0b146 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -183,7 +183,7 @@ https://github.com/bitcoin/bitcoin/pull/6312
Credit goes to Gregory Maxwell for providing a succinct and clear description of the behavior of this change, which became the basis of this BIP text.
-This BIP was edited by BtcDrak and Nicolas Dorier.
+This BIP was edited by BtcDrak, Nicolas Dorier and kinoshitajona.
==Deployment==
@@ -193,20 +193,20 @@ It is recommended to deploy BIP68 and BIP112 at the same time as this BIP.
==Compatibility==
-The only use of sequence valuenumbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.
+The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.
-There may be other uses for the sequence valuenumber field that are not commonplace or yet to be discovered. To allow for other uses of the sequence valuenumber field, it is only interpreted as a relative lock-time as described in this BIP if the most significant bit is clear. This allows up to 31 bits of the sequence valuenumber field to be used for other purposes in applications which don't simultaneously need a per-input relative lock-time. In addition, the unused low-order bits of the relative lock-time encoding are available for use by future soft-fork extensions.
+As can be seen from the specification section, a number of bits are undefined by this BIP to allow for other use cases by setting bit (1 << 31) as the remaining 31 bits have no meaning under this BIP. Additionally, bits (1 << 23) through (1 << 30) inclusive have no meaning at all when bit (1 << 31) is unset.
-The most efficient way to calculate sequence valuenumber from relative lock-time is with bit masks and shifts:
+The most efficient way to calculate sequence number from relative lock-time is with bit masks and shifts:
<pre>
// 0 <= nHeight < 65,535 blocks (1.25 years)
- nSequence = nHeight << 14;
- nHeight = nSequence >> 14;
+ nSequence = nHeight;
+ nHeight = nSequence;
// 0 <= nTime < 33,554,431 seconds (1.06 years)
- nSequence = 1<<30 | (nTime << 5);
- nTime = (nSequence ^ 1<<30) >> 5;
+ nSequence = (1 << 22) | (nTime >> 9);
+ nTime = (nSequence & 0x0000ffff) << 9;
</pre>
==References==