Glossary

Miner Signaling

The process by which Bitcoin miners indicate support for a proposed soft fork by setting specific bits in block headers.

Key Takeaways

  • Miner signaling is a coordination mechanism: miners set specific version bits in the block header to indicate they have upgraded their software and are ready to enforce new soft fork rules.
  • Signaling indicates readiness, not a vote: miners are communicating that their nodes can validate the new rules. The decision to activate a soft fork ultimately rests with the network of full nodes that enforce consensus rules.
  • Different activation mechanisms set different thresholds: BIP 9 requires 95% of blocks in a difficulty period, Speedy Trial (used for Taproot) lowered this to 90%, and BIP 8 with LOT=true adds mandatory signaling as a backstop to prevent miner vetoes.

What Is Miner Signaling?

Miner signaling is the process by which Bitcoin miners indicate their readiness to enforce a proposed soft fork upgrade. Rather than flipping a global switch, Bitcoin upgrades require a decentralized coordination step where miners show that their software has been updated and can validate the new consensus rules. They do this by setting a designated bit in the nVersion field of each block header they produce.

The concept was formalized in BIP 9, titled "Version bits with timeout and delay," which replaced the older method of incrementing the block version number for each upgrade. BIP 9 allows up to 29 independent soft fork proposals to be signaled simultaneously, each tracked by its own bit in the version field. This parallel signaling capability was a significant improvement over the sequential approach used for earlier upgrades.

How It Works

The signaling mechanism relies on the 4-byte nVersion field in every Bitcoin block header. Under BIP 9, the top three bits of this field are fixed to 001, constraining valid version values to the range 0x20000000 through 0x3FFFFFFF. The remaining 29 low-order bits are available for signaling, with each bit assigned to a specific soft fork proposal.

The BIP 9 State Machine

Each soft fork deployment follows a defined state machine with five possible states:

  1. DEFINED: the proposal exists but has not reached its start time. No signaling is expected.
  2. STARTED: the proposal's start time has passed. Miners can begin setting the assigned bit in blocks they mine.
  3. LOCKED_IN: the signaling threshold has been met in a complete difficulty retarget period. Activation is now guaranteed after one more period.
  4. ACTIVE: the new consensus rules are being enforced by the network.
  5. FAILED: the timeout has passed without reaching the threshold. The proposal did not activate.

State transitions are evaluated at the boundary of each difficulty retarget period (every 2,016 blocks, roughly two weeks). The network counts how many of the previous 2,016 blocks have the relevant bit set. If the count meets or exceeds the threshold, the state advances.

Threshold and Timing Parameters

BIP 9 specifies the following parameters for mainnet deployments:

ParameterMainnet ValueTestnet Value
Retarget period2,016 blocks2,016 blocks
Threshold1,916 blocks (95%)1,512 blocks (75%)
Start timeDefined per proposalDefined per proposal
TimeoutDefined per proposal (typically 1 year)Defined per proposal

When no soft forks are being signaled, miners set the version field to 0x20000000 (the bare prefix with no signaling bits set). After a proposal succeeds or times out, its assigned bit enters a fallow period before it can be reused for a different proposal.

Reading a Signal in the Block Header

The nVersion field is interpreted as a 32-bit little-endian integer. To check whether a block signals for a proposal assigned to bit N, you test whether bit N is set:

# Check if bit N is set in the block version
# Example: SegWit used bit 1, Taproot used bit 2

version = 0x20000002  # binary: 001 + bit 1 set
bit_number = 1

is_signaling = (version >> bit_number) & 1 == 1
# True: this block signals for the proposal on bit 1

Signaling vs. Voting

A common misconception is that miner signaling constitutes a vote on whether a soft fork should activate. In practice, signaling is closer to a readiness check: miners indicate that they have upgraded their software and can validate the new rules. The distinction matters because full nodes, not miners, ultimately enforce Bitcoin's consensus rules.

If miners signal for a soft fork but node operators do not upgrade, the new rules will not be enforced by the broader network. Conversely, the 2017 SegWit activation demonstrated that node operators and economic actors can compel miners to signal through mechanisms like the User-Activated Soft Fork (UASF).

Historical Examples

SegWit Activation (2017)

The SegWit upgrade exposed the limitations of BIP 9's 95% threshold. Despite broad support from developers, exchanges, and node operators, a significant minority of miners refused to signal for over a year. The 95% requirement gave this minority an effective veto over the upgrade.

The deadlock was broken through a combination of BIP 148 (a UASF that would reject non-signaling blocks after August 1, 2017) and BIP 91 (a miner-side compromise that lowered the threshold to 80% over a 336-block window). Miners adopted BIP 91 before the UASF deadline, SegWit locked in, and it activated in August 2017. The episode demonstrated that miner signaling alone does not determine the outcome of protocol upgrades.

Taproot Activation (2021)

Learning from the SegWit experience, the Taproot upgrade used a mechanism called "Speedy Trial." This approach gave miners roughly three months to signal support with a 90% threshold (1,815 of 2,016 blocks). If they failed to reach the threshold in that window, the deployment would simply expire, giving the community time to regroup. Mining pools representing over 90% of hashrate signaled support, and Taproot locked in during June 2021 before activating at block 709,632 in November 2021.

CTV Signaling (2026)

The OP_CTV (BIP 119) activation client uses version bit 5 with a 90% threshold and a signaling window that opened in March 2026. As of mid-2026, no covenant opcode has activated on mainnet. The CTV activation debate has reignited discussions about the appropriate role of miner signaling in protocol upgrades and whether readiness signals can be conflated with community consensus.

BIP 8 and LOT=true

BIP 8 is an alternative activation mechanism that builds on BIP 9 but introduces a critical parameter: lockinontimeout (LOT). This parameter determines what happens if miners fail to reach the signaling threshold before the deployment's timeout:

  • LOT=false: the deployment fails quietly, identical to BIP 9 behavior. Miners retain the ability to block activation by not signaling.
  • LOT=true: mandatory signaling is enforced during the last signaling period before the timeout height. Blocks that do not set the required bit are rejected by nodes running this configuration. This guarantees lock-in regardless of miner preference.

The LOT=true approach was designed to prevent miners from vetoing upgrades that have broad community support. Critics argue that it increases the risk of chain splits if the community is not truly aligned, since miners who have not upgraded would produce blocks that LOT=true nodes reject.

BIP 8 has never been used for a mainnet activation. Taproot ultimately activated through Speedy Trial (a BIP 9 variant), though the LOT=true debate influenced the design of that process.

Why It Matters

Miner signaling is a critical coordination tool in Bitcoin's governance model. Because Bitcoin has no central authority that can mandate upgrades, the network relies on signaling mechanisms to gauge readiness and coordinate activation across thousands of independent operators.

The choice of activation mechanism directly affects the power dynamics between miners, node operators, developers, and economic actors. BIP 9 gives miners significant influence (a 5% minority can block activation), while BIP 8 LOT=true shifts power toward node operators. Speedy Trial attempts a middle ground by giving miners a short window to signal before the process resets.

For Layer 2 protocols and applications built on Bitcoin, soft fork activation is especially consequential. Upgrades like Taproot and proposed covenant opcodes like CTV expand what can be built on Bitcoin's base layer, enabling more expressive spending conditions, improved privacy, and new scaling approaches. The signaling process determines when these capabilities become available.

Risks and Considerations

Miner Veto Power

High signaling thresholds (95% under BIP 9) give a small minority of hashrate the ability to indefinitely block upgrades, even those with overwhelming support from developers, businesses, and node operators. This veto power was never intended by BIP 9's designers, who viewed signaling as a readiness indicator rather than a governance mechanism.

False Signals

Signaling is effectively free: setting a bit in the block header costs nothing and requires no actual software upgrade. Miners can signal support without running compatible software, which risks premature activation if a significant portion of hashrate is not actually enforcing the new rules. This could lead to chain reorganizations if non-upgraded miners produce invalid blocks.

Conflating Readiness with Consensus

Miner signaling measures miner readiness, not community consensus. A soft fork could reach the signaling threshold without broad support among users and developers, or it could have overwhelming community support but fail to reach the miner threshold. Neither scenario produces a good outcome. The SegWit activation crisis and the ongoing CTV debate both illustrate this tension.

Chain Split Risk

If different factions of the network run incompatible activation rules (for example, some nodes enforcing LOT=true while others do not), the network could split into competing chains. This risk is highest when the community is divided on whether an upgrade should activate at all, rather than simply on the timing.

For a deeper look at how soft fork activation has evolved over Bitcoin's history, see the research article on Bitcoin soft fork activation history. For an introduction to the covenant opcodes currently under debate, see the CTV deep dive.

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.