BIP 90 Buried Deployments Explained: Historical Rules in Bitcoin Core

BIP 90 buried deployments explained: see how Bitcoin Core replaced historical activation checks with fixed-height consensus assumptions.

What burying a deployment mean

A buried deployment is an old consensus change whose activation machinery has been replaced in current software by a fixed historical height or equivalent chain parameter. The rule remains fully enforced after that point. What is buried is the obsolete signalling and transition logic, not the consensus requirement or the historical blocks that established the active chain.

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.

The deployments covered by BIP 90

BIP 90 addressed BIP 34 height-in-coinbase, BIP 65 CHECKLOCKTIMEVERIFY and BIP 66 strict DER signatures. Each had activated long before the proposal. Replaying rolling block-version thresholds forever added complexity and could produce surprising state on unusual chains. Fixed heights make the intended mainnet history explicit and easier for implementations to reason about.

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.

Why historical signalling can be removed

Once a rule is deeply established, every practical main-chain tip lies well beyond activation. Recalculating readiness windows no longer helps normal validation. Buried constants reduce code paths and eliminate the possibility that a very deep reorganisation accidentally returns the state machine to an obsolete phase. They also document a minimum historical assumption built into that client release.

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.

What is still validated

Nodes continue checking block height commitments, strict signature encoding and CLTV wherever the active rules require them. Burying does not turn invalid transactions valid or exempt old blocks from all verification. Initial block download still verifies the chain according to software rules, checkpoints, assumed-valid policy and user configuration. Those mechanisms should not be conflated with buried deployments.

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.

Alternative chains and testing

A private or alternative chain that reuses Bitcoin code may not share mainnet activation heights. Hard-coded buried values can be inappropriate there. Regtest and signet parameters are intentionally separate. Developers should select the correct chain configuration and tests instead of altering mainnet constants for convenience, because an accidental mismatch can make nodes reject each other far from the current tip.

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.

Operational relevance for miners

Normal mainnet pools do not signal for these historical deployments. Their current nodes simply enforce the rules. The operational risk appears when restoring ancient software, running a forked client or building custom chain parameters. Compare the exact consensus constants across primary and failover nodes before hashing, and never assume that matching current tip text proves matching historical validity.

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.

Audit checklist

Record client version, network, genesis hash and buried activation heights. Reindex a test copy when changing implementations and compare selected historical validation results. Confirm that getblocktemplate reports only currently relevant deployments. If documenting old version-bit data, label it as history rather than an actionable signal. Keep consensus parameter changes under code review with reproducible chain tests.

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 BIP 90 buried deployments 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

Bip 90 buried deployments 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.