Getblocktemplate required rules made simple. See the main facts, costs, risks and practical checks before you make a decision.
Learn how getblocktemplate required rules, vbavailable, vbrequired and the rules array keep Bitcoin pool templates aligned with active consensus changes.
The getblocktemplate RPC gives mining software the data needed to construct a candidate block. A client can list soft-fork deployment names it supports in the request’s rules array. During a version-bits deployment, vbavailable maps pending deployment names to their bit numbers. Vbrequired is a bit mask for version bits the server requires in submitted blocks.
Getblocktemplate required rules: The getblocktemplate RPC gives mining software the data needed to construct a candidate block. BIP22 replaced the older idea of a node supplying only a header with a richer template containing the previous block hash, target, transactions, time, height and coinbase information.
A node operator is checking getblocktemplate required rules. If those facts are unknown, the operator cannot show which rules were actually applied before electricity was committed to the work.
The getblocktemplate RPC gives mining software the data needed to construct a candidate block. BIP22 replaced the older idea of a node supplying only a header with a richer template containing the previous block hash, target, transactions, time, height and coinbase information. The miner or pool can customise permitted fields, then submit a completed block for validation.
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.
A client can list soft-fork deployment names it supports in the request’s rules array. The server returns active rules in its response. Names prefixed with an exclamation mark identify changes that affect template use in a way the client must understand. If a client does not understand such a required rule, it must not process or mine that template.
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.
During a version-bits deployment, vbavailable maps pending deployment names to their bit numbers. A miner may adjust available bits within the specification’s limits. The returned version remains the server’s preference. Blindly replacing the whole version value can erase required signalling, collide with another deployment or make later diagnostics impossible.
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.
vbrequired is a bit mask for version bits the server requires in submitted blocks. BIP8 specifies that servers set it during MUST_SIGNAL. A client may only clear a bit offered in vbavailable when it is not also required. This is a machine-readable safety boundary between flexible version rolling and a candidate the validating server will reject.
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.
Some upgrades change more than transaction validity. SegWit added a witness commitment to the coinbase transaction and changed transaction-identification details. BIP145 updated getblocktemplate so a capable client can request and correctly construct SegWit blocks. A hashing device that knows only a header cannot solve missing coinbase commitments. The template layer must build them correctly first.
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.
Template mode asks for work. Proposal mode lets software validate a proposed block without submitting it to the peer network, where supported. Submitblock sends a completed block and returns a rejection reason or null on acceptance. Pools should retain these results because an accepted share is not necessarily a valid network block, and a valid-looking hash can still fail consensus or construction checks.
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.
Log the node version, best block hash, rules, vbavailable, vbrequired, target and template age. Alert when redundant providers disagree, a required rule is unknown or long polling stops updating work. Test failover using real schema checks rather than a port probe. For decentralised job selection, also document which component chooses transactions and which validating node performs final proposal checks.
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.
A concise decision record for getblocktemplate required rules 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.
Getblocktemplate required rules 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.
Getblocktemplate required rules: The getblocktemplate RPC gives mining software the data needed to construct a candidate block.
The getblocktemplate RPC gives mining software the data needed to construct a candidate block.
A client can list soft-fork deployment names it supports in the request's rules array.
During a version-bits deployment, vbavailable maps pending deployment names to their bit numbers.
Primary specifications are living technical records. Check their current status and changelog before using this article for a production activation decision.
See how OCEAN DATUM Gateway mining lets your node build Bitcoin work while a compatible pool records shares, plus the setup, security and failover checks.
Learn how Stratum V2 pool fallback works, what it can earn, the costs and security checks, and how a Bitcoin node can support SHA-256 miners.
Stratum V2 Job Declaration explained: see how miner-selected templates, job tokens, missing transactions and pool payouts fit together.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.