BIP 320 Explained: General-Purpose Version Bits for Bitcoin Mining

BIP 320 version bits explained: understand the general-purpose mask, ASICBoost use, signalling separation and safe pool negotiation.

What the proposal changes

BIP 320 designates a subset of the block header version field as general-purpose bits that miners may vary for optimisation without those changes being assigned soft-fork signalling meaning. It reduces collisions between mining hardware’s need for extra search space and the interpretation of version bits by deployment state machines.

The rule should be read from the primary specification and tested against the exact node release used in production.

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.

Fields and encoding

The proposal defines the mask 0x1fffe000, covering bits 13 through 28 under the stated numbering. The top pattern used by version-bits signalling and lower deployment space remain constrained separately. A mask is a permission boundary: miners may vary only positions that the template provider and protocol negotiation allow.

Byte order, length and units matter. A plausible human-readable value can still encode a different consensus or protocol meaning.

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.

Validation boundary

General-purpose does not mean ignored by every conceivable client or safe forever without negotiation. Nodes still validate the complete header version according to active rules. Pools combine their base template version with miner-supplied bits, and must prevent changes to required signalling or reserved patterns. ASICs hash work derived from this decision.

At the same time, the validating node or pool service remains responsible for accepting the underlying block and transactions.

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.

Why miners care

Version rolling gives ASICs more candidate headers while retaining the same transaction set and previous block. It is associated with overt AsicBoost and nonce-space management. The technique changes work generation, not the probability per hash, subsidy, fees or the obligation to validate the selected block template.

The practical effects include template correctness, propagation latency, stale-share exposure and whether a solved candidate earns a recognised reward.

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.

Failure modes

Endianness mistakes make masks look correct in logs but alter the wrong positions. Firmware may overwrite instead of merge the base version. A failover pool may negotiate fewer bits, and stale cached masks can conflict with a new job. Invalid shares should be diagnosed from reconstructed 80-byte headers.

Monitoring should preserve raw messages and rejection reasons so an operator can distinguish a network delay from malformed work or incompatible policy.

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.

Deployment and compatibility

BIP 320 complements BIP 310’s Stratum extension negotiation. It does not itself define pool messages or require every server to expose the entire mask. Newer job protocols can express capabilities differently. Operators should document the effective intersection of consensus, pool policy, protocol and hardware support. Historical assignment dates anchor these articles.

But current deployments may have extra later standards. Pin versions rather than assuming uniform peer support.

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.

Operator verification checklist

Record base versions, offered and accepted masks, miner version_bits and reconstructed effective headers. Exercise zero, full-mask, out-of-mask and reconnect cases. Verify pool and node proposal acceptance around deployment transitions, and alert when a firmware update changes rolling behaviour or share rejection rates.

Repeat the same test across primary and failover paths, retain timestamps and define a pause condition before changing production mining configuration.

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 320 version bits 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 320 version bits 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.