BIP9 / Version Bits

BIP9, commonly called version bits, is a mechanism for activating Bitcoin soft forks by treating the 32-bit version field of the block header as a bitfield. Each pending soft fork is assigned one bit (from 0 to 28); miners set that bit in the blocks they produce to signal readiness, while the bit is used only for signaling and never to reject a block as invalid. Because each proposal owns its own bit, several upgrades can be in flight simultaneously without conflicting — a significant improvement over the earlier scheme of incrementing the whole version number, which forced upgrades to queue one behind another.

How activation progresses

BIP9 deployments move through defined states — DEFINED, STARTED, LOCKED_IN, ACTIVE, and FAILED — evaluated at each 2,016-block retarget boundary, the same cadence as the difficulty adjustment. If at least 95% of blocks in a retarget period signal the bit (1,916 of 2,016 on mainnet), the deployment locks in for one further retarget period, giving laggards time to upgrade, and then becomes active and enforced. If a configured timeout passes without the threshold being reached, the attempt fails cleanly and the unused logic can be removed from later releases — the bit is recycled rather than burned forever. The top three version bits are fixed to 001, so signaling values fall in the range 0x20000000–0x3FFFFFFF; this framing also explains the otherwise odd-looking version numbers visible in any block explorer.

What miners are actually doing

A common misreading is that BIP9 lets miners "vote" on protocol rules. It does not: full nodes define and enforce the rules; miner signaling is a coordination measurement, indicating that enough hashrate has upgraded that the new rules can activate without splitting the chain through accidentally invalid blocks. A miner signaling a bit is saying "my software is ready," not "I approve." That distinction became load-bearing during the SegWit era, when signaling was withheld for reasons unrelated to readiness.

For miners, signaling is a one-line configuration reality rather than a governance ceremony: pool software sets the version bits on the block templates it distributes, so in practice a pool operator signals on behalf of all the hashrate pointed at it — one more quiet argument for miners caring who builds their templates. For node operators, RPC calls such as getdeploymentinfo expose deployment states directly, letting anyone audit an activation in real time instead of trusting commentary. The states are objective facts of the chain, computable by any node from block data alone — no announcement, foundation, or website is part of the mechanism.

Limitations and successors

BIP9's reliance on a 95% threshold meant a small minority of hashrate could indefinitely stall an otherwise popular change — a veto the design never intended. The SegWit standoff exposed this, and the community response was layered: the UASF movement (BIP148) demonstrated that economic nodes could force the issue regardless of miner signaling, and later designs generalized the lesson. BIP8 can force lock-in at a block height whether or not signaling reaches threshold, and the "Speedy Trial" variant used to activate Taproot in 2021 used a short, fixed signaling window with a lock-in-on-timeout backstop debate behind it. Every activation since has been shaped by this history: signaling smooths coordination, but sovereignty over the rules stays with the nodes users run.

Version bits remains the signaling layer beneath modern upgrades and a clean case study in how Bitcoin changes without a central authority: proposals earn activation through measured readiness, not decree. See the broader soft fork upgrade model for how backwards-compatible rule tightening works in the first place.

Full open-data reference: Bitcoin BIPs Reference — CSV / JSON + REST API, CC BY 4.0.