BIP 112 CHECKSEQUENCEVERIFY Explained for Miners and Nodes

BIP 112 CHECKSEQUENCEVERIFY explained: understand relative Script delays, sequence flags, Lightning recovery paths and node validation.

What CHECKSEQUENCEVERIFY does

CHECKSEQUENCEVERIFY, or CSV, lets a script require a relative delay encoded through the spending input’s sequence field. It redefines NOP3 when the rule is active. The script can therefore offer one immediately authorised branch and another branch that becomes valid only after the output has aged, without knowing the future confirmation height when the output is created.

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.

CSV checks rather than waits

CSV reads a stack value and checks transaction version, sequence disable flags, lock type and the encoded delay. It does not pause execution or maintain a timer. The validation result follows deterministically from the transaction and chain context supplied by BIP 68. A successful CSV leaves the value on the stack. So scripts normally use DROP before continuing.

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.

Block delay versus time delay

CSV can express block-based or time-based relative locks. The type in the script operand must match the transaction sequence type, and the transaction delay must be at least the required value. Time uses 512-second units and median-time-past semantics. Contract documentation should state the encoded form, approximate duration and operational consequence if block production or timestamps vary.

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.

Delayed recovery paths

CSV is useful when one party can spend cooperatively at once but a backup or unilateral path should wait. Payment channels use relative delays to create a reaction window. At the same time, vault-like designs can provide a recovery opportunity. The opcode supplies only the delay condition. Key management, monitoring, fee strategy and branch correctness determine whether the recovery actually works.

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.

Lightning relevance

Lightning commitment transactions use delayed outputs so a counterparty can respond to an obsolete state and so unilateral closure follows defined timing. Details depend on the channel script and protocol version. A mining operator need not interpret every channel. But its node must validate CSV correctly and relay mature transactions consistently for wallets and fee-bump mechanisms to function.

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.

Mining-node requirements

CSV spends are ordinary consensus-checked transactions once mature. Template nodes must enforce BIP 68 and BIP 112 together, refresh candidates on a new tip and reject mismatched or premature scripts. An ASIC receives only derived work. Pools should ensure every validating backend and failover uses compatible active-chain rules, especially around historical reindex or restored-node operations.

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.

Contract test plan

On regtest, construct cooperative and delayed branches, then try them before and after the boundary. Test version one, disabled sequence, mismatched types and insufficient delays. Reorganise the funding confirmation and confirm eligibility changes. Keep raw scripts and transactions in the evidence pack. A wallet saying recoverable soon is less authoritative than successful validation in the intended block context.

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 112 CHECKSEQUENCEVERIFY 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 112 checksequenceverify 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.