1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-03 18:57:18 +01:00

Correct the claim that only 29 bits are available anyway

This commit is contained in:
Pieter Wuille 2016-03-02 19:59:18 +01:00
parent cd6dfb9411
commit a3df16e650

View file

@ -48,12 +48,16 @@ With each block and soft fork, we associate a deployment state. The possible sta
====Bit flags==== ====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 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 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.
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) Due to the constraints set by BIP 34, BIP 66 and BIP 65, we only have 0x7FFFFFFB possible nVersion values available.
requirement already makes that impossible. When a block nVersion does not have top bits 001, it is treated as if all This restricts us to at most 30 independent deployments. By restricting the top 3 bits to 001 we get 29 out of those
bits are 0 for the purposes of deployments in the context of this BIP. Miners should continue setting the bit in for the purposes of this proposal, and support two future upgrades for different mechanisms (top bits 010 and 011).
LOCKED_IN phase, so uptake is visible 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==== ====New consensus rules====