diff options
author | Pieter Wuille <pieter.wuille@gmail.com> | 2016-03-02 19:59:18 +0100 |
---|---|---|
committer | Pieter Wuille <pieter.wuille@gmail.com> | 2016-03-02 20:09:36 +0100 |
commit | a3df16e6504769498c51af88afd4cf2148896bd0 (patch) | |
tree | f013863cb9cbda403204b1f2f20c4a547566ba46 | |
parent | cd6dfb94116224d552b3cc884b3454deeeaf0ad8 (diff) | |
download | bips-a3df16e6504769498c51af88afd4cf2148896bd0.tar.xz |
Correct the claim that only 29 bits are available anyway
-rw-r--r-- | bip-0009.mediawiki | 16 |
1 files changed, 10 insertions, 6 deletions
diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki index ef7a2ab..7ef014d 100644 --- a/bip-0009.mediawiki +++ b/bip-0009.mediawiki @@ -48,12 +48,16 @@ With each block and soft fork, we associate a deployment state. The possible sta ====Bit flags==== Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be -001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. This leaves two future -upgrades for different mechanisms (top bits 010 and 011), while complying to the constraints set by BIP 34 and others. -Having more than 29 available bits for parallel soft forks does not add anything anyway, as the (nVersion >= 3) -requirement already makes that impossible. When a block nVersion does not have top bits 001, it is treated as if all -bits are 0 for the purposes of deployments in the context of this BIP. Miners should continue setting the bit in -LOCKED_IN phase, so uptake is visible +001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive. + +Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available. +This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those +for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011). +When a block nVersion does not have top bits 001, it is treated as if all +bits are 0 for the purposes of deployments. + +Miners should continue setting the bit in LOCKED_IN phase so uptake is visible, though this has no effect on +consensus rules. ====New consensus rules==== |