summaryrefslogtreecommitdiff
path: root/bip-0068.mediawiki
diff options
context:
space:
mode:
authorBtcDrak <btcdrak@gmail.com>2015-11-20 19:32:36 +0000
committerBtcDrak <btcdrak@gmail.com>2015-11-23 09:53:31 +0000
commitf26cc0c4d35a1a5e4e05802afed7da122dcda672 (patch)
treef099cfe4c0928b3299a46d12821f4e26729d3e8d /bip-0068.mediawiki
parent060c37f6d530881e4e5b06a711244adb2d18a7de (diff)
downloadbips-f26cc0c4d35a1a5e4e05802afed7da122dcda672.tar.xz
Clarify (1 << 22) logic
Diffstat (limited to 'bip-0068.mediawiki')
-rw-r--r--bip-0068.mediawiki4
1 files changed, 2 insertions, 2 deletions
diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 8077d08..fff1092 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -32,9 +32,9 @@ The sequence number encoding is interpreted as follows:
Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past (MTP) of the output’s previous block, and ends either at the MTP of the previous block or at the nTime of the transaction’s block (depending on the enforcement status of BIP113). If the bit is not set, the relative lock-time specifies a number of blocks.
-Note (1 << 22) was chosen because it is the highest you can go without moving to 4-byte pushes when using the Bitcoin scripting language in conjunction with OP_CHECKSEQUENCEVERIFY: i.e. 3 bytes = 24 bits where pushes are signed integers which leaving 1 bit for the flag and 22 bits for the relative lock-time encoding.
+The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112).
-This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time. This is to allow for future expansion. The specification allows for a year of relative lock-time.
+This specification only interprets 16 bits of the sequence number as relative lock-time, so a mask of 0x0000ffff MUST be applied to the sequence field to extract the relative lock-time. The 16-bit specification allows for a year of relative lock-time and the remaining bits allow for future expansion.
For time based relative lock-time, 512 second granularity was chosen because bitcoin blocks are generated every 600 seconds. So when using block based or time based relative lock-time, the same amount of time can be encoded with the available number of bits. Converting from a sequence number to seconds is performed by multiplying by 512 = 2^9, or equivalently shifting up by 9 bits.