Correct the claim that only 29 bits are available anyway

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