diff options
| -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==== |