Version Bits (BIP 9)

What Is Version Bits?

Version bits (formally defined in BIP 9) is a mechanism that lets Bitcoin miners signal their readiness for proposed soft fork upgrades using individual bits in the block header's nVersion field. Each bit position represents a different proposal, so multiple upgrades can be coordinated in parallel without interfering with each other.

Before BIP 9, Bitcoin used a simpler method called IsSuperMajority (ISM) that relied on incrementing the block version number sequentially. This meant only one upgrade could be in progress at a time, and it provided no clean way for a failed proposal to expire. Version bits replaced ISM with a more flexible system that includes defined start times, timeouts, and a formal state machine governing each deployment's lifecycle.

BIP 9 was authored by Pieter Wuille, Peter Todd, Greg Maxwell, and Rusty Russell. It was first used on mainnet for the activation of CSV (BIP 68, BIP 112, BIP 113) in 2016 and subsequently for SegWit in 2017.

How It Works

The nVersion field in a block header is a 32-bit integer. BIP 9 constrains the top three bits to 001, which means valid signaling blocks have nVersion values in the range 0x20000000 to 0x3FFFFFFF. The remaining 29 bits (positions 0 through 28) are available for signaling individual soft fork proposals.

When a miner wants to signal support for a proposal assigned to bit N, they set that bit in their block's nVersion field. A miner can signal for multiple proposals simultaneously by setting multiple bits:

// nVersion field structure (32 bits)
// Top 3 bits: 001 (required by BIP 9)
// Bits 0-28: available for signaling

0x20000000  // Base value, no signaling (001 + 29 zeros)
0x20000001  // Signaling for bit 0 (used by CSV)
0x20000002  // Signaling for bit 1 (used by SegWit)
0x20000004  // Signaling for bit 2 (used by Taproot)
0x20000003  // Signaling for both bit 0 and bit 1

The State Machine

Each soft fork deployment follows a five-state lifecycle. Transitions are only evaluated at retarget period boundaries (every 2,016 blocks):

1. DEFINED: the initial state for every deployment. The proposal exists in the code but signaling has not yet begun. Remains here until the start time is reached.
2. STARTED: signaling begins once the median time past (MTP) of a block reaches the deployment's start time. Miners can now set the assigned bit in their blocks.
3. LOCKED_IN: if at least 1,916 out of 2,016 blocks (95% on mainnet) in a retarget period have the deployment bit set, the proposal locks in. Activation is now guaranteed.
4. ACTIVE: the new consensus rules are enforced starting at the next retarget period after lock-in. This is a terminal state.
5. FAILED: if the MTP reaches the timeout without achieving lock-in, the proposal expires. The bit is freed for reuse. This is also a terminal state.

Parameters

Each BIP 9 deployment specifies several parameters:

Both starttime and timeout are compared against the median time past (MTP) of blocks rather than raw timestamps. MTP is the median of the previous 11 blocks' timestamps, providing a monotonically increasing clock that is harder for miners to manipulate.

Historical Deployments

CSV Activation (2016)

The first mainnet deployment using BIP 9 was CSV: a bundle of three BIPs (BIP 68 for relative lock-time, BIP 112 for OP_CHECKSEQUENCEVERIFY, and BIP 113 for median time past in lock-time calculations). CSV used bit 0 and reached lock-in when 1,946 out of 2,016 blocks (96.5%) signaled support. It activated at block 419,328 on July 4, 2016.

CSV's smooth activation validated the version bits approach. The parallel signaling capability and clean timeout mechanism both worked as designed.

SegWit Activation (2017)

SegWit (BIP 141) was assigned bit 1 with a start time of November 15, 2016, and a timeout of November 15, 2017. Despite broad community support, miner signaling stalled at roughly 30% for months.

The stalemate was driven by several factors: some miners opposed SegWit's approach to scaling, others wanted to preserve covert ASICBoost (a mining optimization that SegWit's transaction commitment changes would disable), and the 95% threshold allowed a small minority of hashrate to block activation indefinitely.

Resolution came through a combination of UASF pressure (BIP 148, which would reject non-signaling blocks after August 1, 2017) and BIP 91 (which required SegWit signaling once 80% of a 336-block window signaled on a separate bit). SegWit ultimately locked in on August 9, 2017, with 100% signaling, and activated at block 481,824 on August 24, 2017.

Criticism and Evolution

The SegWit activation crisis exposed a fundamental flaw in BIP 9: the 95% threshold transformed miners from "readiness signalers" into "gatekeepers" of protocol changes. A mere 5% of hashrate could veto any upgrade, regardless of broader community consensus. This turned a technical coordination mechanism into a political tool.

BIP 8: Lock-in by Height

BIP 8 was developed as BIP 9's successor, addressing its key shortcomings:

• Uses block heights instead of timestamps for timing, making transitions deterministic
• Introduces the LOT (lockinontimeout) parameter: when set to true, blocks that do not signal become invalid in the final retarget period before timeout, guaranteeing activation
• Adds a minimum_activation_height parameter that decouples lock-in from activation, giving node operators time to upgrade
• Recommends a 90% threshold (1,815 of 2,016 blocks) rather than 95%

The LOT=true option is controversial: it guarantees activation but risks a chain split if some nodes enforce mandatory signaling while others do not. The tension between LOT=true and LOT=false reflects a deeper debate about who ultimately controls Bitcoin's protocol: miners, node operators, or developers.

Speedy Trial and Taproot

For Taproot activation (BIP 340, BIP 341, BIP 342), the community adopted Speedy Trial: a modified BIP 9 approach with a compressed timeline and lower threshold. It was designed as a low-risk first attempt: if miners signal quickly, the upgrade activates; if they do not, the community loses nothing and can try a different approach.

Taproot used bit 2, with signaling starting April 24, 2021, and a timeout of August 11, 2021. It locked in at block 687,284 on June 12, 2021, after exceeding 90% support, and activated at block 709,632 on November 14, 2021. The smooth activation validated Speedy Trial as an effective approach for uncontroversial upgrades. For a deeper history of these activation methods, see the Bitcoin soft fork activation history research article.

Why It Matters

Version bits established the foundation for how Bitcoin evolves. Every major soft fork since 2016 has used some variant of the BIP 9 signaling framework. The mechanism balances several competing concerns: giving miners a voice in activation timing, providing clear success and failure criteria, and enabling multiple proposals to proceed in parallel.

For users and developers building on Bitcoin and its layer-2 protocols, understanding version bits is essential for tracking upcoming protocol changes. Features like Taproot, Schnorr signatures, and Tapscript all activated through this process. Future proposals such as OP_CAT and CTV would likely use similar signaling mechanisms, making version bits an ongoing part of Bitcoin's governance model.

The lessons from version bits also shaped how layer-2 protocols like the Lightning Network and Spark approach upgrades: with clear signaling, defined activation windows, and fallback paths when consensus is not reached.

Risks and Considerations

Miner Centralization Risk

Version bits assumes that hashrate distribution is sufficiently decentralized for signaling to reflect genuine readiness. If a small number of mining pools control a majority of hashrate, they can coordinate to block or rush proposals, undermining the mechanism's purpose as a readiness gauge.

Signaling vs. Enforcement

BIP 9 signaling is advisory: miners can signal support without actually enforcing the new rules. This "false signaling" risk means that lock-in does not guarantee all miners have upgraded their software. If a significant portion of hashrate activates without enforcement, it could produce invalid blocks after activation, potentially causing temporary chain reorganizations.

Threshold Tradeoffs

The choice of threshold involves a fundamental tension. A high threshold (95%) ensures near-universal readiness but grants veto power to small minorities. A lower threshold (90%) reduces veto risk but increases the chance of activating before all miners are prepared. No threshold eliminates both risks simultaneously.

Bit Exhaustion

While 29 bits seem ample, BIP 320 reserved 16 of them (bits 13 through 28) for general-purpose miner use such as extra nonce space. This reduces the practical signaling capacity to 13 bits. If many proposals are in-flight simultaneously, bit assignments could become contested.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.