BIP9 Miner Signalling Explained: Started, Locked In and Active

BIP9 miner signalling explained through DEFINED, STARTED, LOCKED_IN, ACTIVE and FAILED states, including retarget windows and pool checks.

What BIP9 miner signalling does

BIP9 treats selected bits in the 32-bit block-version field as readiness signals for parallel soft-fork deployments. Each deployment has a name, bit, start time, timeout and threshold. The mechanism coordinates a predictable state machine. It does not let a pool invent rules, and a block’s signal does not itself prove that the miner validates those rules correctly.

Start with the validating node, because the ASIC only hashes the candidate header it receives. Record the node release and the pool component that assembled the block. If those facts are unknown, the operator cannot show which rules were actually applied before electricity was committed to the work.

DEFINED and STARTED

A deployment begins in DEFINED. At the first retarget boundary after its start time, it can enter STARTED. Miners can then set the assigned version bit. State is evaluated in 2,016-block periods. So a dashboard that counts a rolling handful of blocks can be useful for trend awareness but is not the authoritative state calculation.

Treat status dashboards as observations, not as the source of truth. Compare them with an independently operated node and retain the raw deployment or template response. Period boundaries, chain reorganisations and cached pool pages can otherwise make a correct-looking percentage describe the wrong state.

How LOCKED_IN is reached

At a retarget boundary, nodes count signalling blocks in the previous period. If the deployment threshold is met, the next period is LOCKED_IN. Lock-in is a commitment in the state machine, not immediate enforcement. That delay gives remaining operators a final, known window to upgrade before blocks violating the new rule are rejected.

Build the failure response before the boundary arrives. Define which rejection messages trigger an alert, who can pause a template source and how failover is prevented from returning miners to the same faulty validation stack. A second hostname is not independent when both endpoints share one node.

ACTIVE and FAILED are terminal

After LOCKED_IN, the deployment moves to ACTIVE following the specified delay, and upgraded nodes enforce the new consensus rules. If the timeout passes without enough signalling, it moves to FAILED. These terminal states prevent later short-term changes in hashrate signalling from switching enforcement backwards and forwards.

Separate readiness, signalling and enforcement in the operating log. Readiness is a claim about software and process, signalling is data carried by blocks, and enforcement is a validation result. Combining them into a single supported or unsupported label hides the point at which revenue is actually at risk.

Taproot’s Speedy Trial example

Bitcoin Core 0.21.1 shipped Taproot activation parameters using Speedy Trial, a variation on BIP9. It used bit 2 and required 90 per cent of a 2,016-block period. The release notes told miners using getblocktemplate that Bitcoin Core would signal automatically. This example shows why an operator must check deployment-specific parameters rather than memorise a single universal threshold.

Map responsibility across the full path: validating node, template server, pool protocol, proxy, firmware and ASIC. For each layer, state what it can alter and what it merely relays. This prevents a version-bit setting in firmware from being mistaken for complete consensus-rule support. Relate that responsibility map to the pool and job-control boundary in our Stratum V2 guide.

What pool and miner dashboards should show

Useful monitoring separates current state, blocks elapsed in the period, signals counted, threshold, estimated boundary and the node software supplying templates. It should also flag disagreement between independent nodes. A percentage without the period boundaries can mislead. At the same time, an ASIC web interface may only reveal pool work and not the validating node behind it.

Test the primary and failover paths with the same checks. Compare chain tip, chainwork, deployment state, required rules and template age, then save the result with a timestamp. The process should be repeatable by another operator without relying on an undocumented pool conversation.

Operational checks before activation

Confirm that production and failover template providers agree on the deployment state and active rules. Test getblocktemplate responses, alert on unexpected version masks and retain block-rejection logs. Do not force an arbitrary version value in firmware merely to make a dashboard look green. The candidate block still has to follow every active consensus rule.

Turn the conclusion into a business decision. State which chain and settlement venues the operation intends to serve, the maximum acceptable stale-block exposure and the point at which mining pauses. This connects protocol evidence to electricity cost, pool revenue and payout finality.

Operator decision record

A concise decision record for BIP9 miner signalling should name the source documents, their dates, the node release tested, the responsible pool or template provider and the exact trigger for action. Include screenshots or machine-readable output for the deployment state. But keep the raw node response as the stronger evidence.

State whether a change affects policy, block construction or consensus validity, because those layers have different failure costs.

Run the check on every production and failover path. Confirm that monitoring alerts on stale templates, unexpected chain tips, rejected proposals and a rise in stale shares. Keep rollback instructions for node and pool configuration. But do not roll back across an active consensus boundary without understanding the rules the older release enforces.

If the evidence conflicts, pause the affected path and investigate before committing more electricity to uncertain work.

For related background, read our plain-English BIP-110 guide and technical BIP-110 review. Those articles use a modern proposal to show why signalling, activation, template construction and accepted chain history must be examined separately.

Conclusion

Bip9 miner signalling is best understood as a defined interaction between validating software, mining infrastructure and economic acceptance. The safest operator does not infer consensus from a dashboard percentage or a pool slogan. They verify the rule source, the activation boundary, the template fields and the chain their payouts ultimately settle on. That discipline reduces the chance of hashing an invalid or commercially unwanted block.