Version Bits (BIP 9 / BIP 8)

Version bits are Bitcoin's standard way for miners to signal readiness for a soft fork by setting individual bits in a block's version field. Defined originally in BIP 9, the scheme lets multiple independent proposals be deployed in parallel, each assigned its own bit, so they can activate separately without colliding. The 32-bit version field in every block header is treated as a bit array: when the top three bits are set to 001, the remaining bits become signaling flags that full nodes tally to decide whether a rule change has enough miner support to lock in.

BIP 9 and its limits

Under BIP 9, a deployment has a start time and a timeout expressed as POSIX timestamps, and moves through defined states: DEFINED, STARTED, LOCKED_IN, ACTIVE, or FAILED. The change locks in once a 2,016-block retarget period sees at least 95% of blocks signaling; otherwise it expires at the timeout. SegWit's activation exposed the weakness: because lock-in depends on near-unanimous hashrate cooperation, a small minority of miners can veto a change the wider community supports, or use signaling as a bargaining chip. That standoff produced the UASF movement and BIP 148, which forced the issue from the node side.

BIP 8 and forced activation

BIP 8 was proposed to address those flaws. It measures the start and timeout windows in block heights instead of timestamps, removing manipulation risk from miners stalling the clock. More importantly it adds a lock-in-on-timeout (LOT) option: when set to true, miners must signal during the final period or risk producing invalid blocks, guaranteeing activation rather than leaving it to miner goodwill. Taproot ultimately activated through Speedy Trial, a short BIP 9-style deployment with a lowered 90% threshold and a delayed activation height — a pragmatic compromise between the two philosophies. The broader menu of approaches is covered under soft-fork activation.

Version bits and version rolling

There is a second, easily confused use of the same field. Overt AsicBoost — the efficiency technique behind version rolling — has mining hardware grind through version-field values as extra nonce space. BIP 320 reserves bits 13 through 28 for that general-purpose use, and the Stratum V1 version-rolling extension negotiates a mask (commonly 0x1fffe000) telling the machine exactly which bits it may scramble; Stratum V2 builds the same negotiation into the core protocol. The two uses coexist precisely because of the mask discipline: deployment signaling lives in the low bits, rolling in the reserved range, and a correctly configured pool ensures a miner never mangles an active signal. When you see wildly varying version numbers across blocks, you are usually looking at rolled entropy, not a flood of new proposals.

Reading the signal yourself

Anyone running a full node can watch a deployment's progress without trusting a tracker website — the tallies are computed from headers you validate yourself. That is the quiet virtue of the version-bits design: coordination happens in public, on-chain, in a form any participant can audit. Miners signal readiness, but nodes enforce the rules; signaling is a coordination tool, not a vote that miners can use to change Bitcoin unilaterally. Understanding that distinction is half of understanding Bitcoin governance.

A little history makes the mechanics concrete. Early deployments assigned CheckSequenceVerify bit 0, SegWit bit 1, and Taproot bit 2, and because bits are recycled after a deployment ends, the same bit can mean different things in different eras — context is the deployment schedule compiled into your node, not the bit number alone. Your own node will report the live state of any active deployment through its RPC interface, which beats trusting a signaling-tracker website. The deeper takeaway for miners is professional: configure your stack so rolled bits stay inside the negotiated mask, and know which deployment bits are live before touching version-field settings, because a malformed version can turn otherwise-valid work into rejected blocks.

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