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:
parent
cd6dfb9411
commit
a3df16e650
1 changed files with 10 additions and 6 deletions
|
@ -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====
|
||||
|
||||
|
|
Loading…
Add table
Reference in a new issue