Solo Mining Calculator: Estimate Odds and Timeframes
Use a solo mining calculator correctly: enter productive hashrate, network conditions, uptime and time horizon, then read expected time and probability without.
Read article
ASIC mining knowledge centre
BIP 23 getblocktemplate for Pooled Bitcoin Mining Explained
BIP 23 getblocktemplate – Pooled Mining made simple. See what the proposal changes, its current status and what it means for Bitcoin users and operators.
This guide explains BIP 23 getblocktemplate – Pooled Mining in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 23 extends BIP 22 getblocktemplate for pooled mining. It defines optional capabilities for proposing candidate blocks, declaring allowed mutations, narrowing nonce and time ranges and abbreviating submissions.
- Why it matters: BIP 23 gives pooled miners a richer, testable getblocktemplate contract. Safe deployment depends on explicit capability negotiation, strict mutation boundaries, proposal validation and failover tests for work identifiers, time and stale templates.
- Current position: Its status is Deployed, but each extension is optional, so miners and pools must negotiate and test the exact subset rather than treating BIP 23 as one indivisible feature flag.
BIP 23 getblocktemplate – Pooled Mining in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of the transaction as a form passed between several authorised signers. Each person or device checks the same payment details before adding approval. Passing the form around does not make the payment safe unless every signer checks what it contains.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- RPC:
- A command that software sends to a node to request information or a local action.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Foundation on BIP 22
BIP 22 supplies the base JSON-RPC block-template contract, while BIP 23 adds pooled-mining extensions. Level-one and level-two support descriptions bundle particular optional features, but a production handshake should still inspect returned capabilities and fields. A server name or version string is not proof of the supported subset.
Block proposal mode
A miner can submit hex-encoded block data in proposal mode before proof of work is found. The server validates the candidate against its normal rules except proof of work and returns null, a rejection reason, a delta template or a work identifier. This catches invalid construction before scarce hashing time is committed.
Mutation permissions
The mutable array tells the client which parts it may change, including coinbase data, time, transactions, previous block or version under defined labels. Permission must be explicit. A client that silently modifies fields outside the declared set can produce rejected shares or an invalid solved block even when the original template was sound.
Nonce and time bounds
noncerange can constrain the header nonce space, while mintime, maxtime and moving offsets bound timestamp updates. These values coordinate distributed workers and prevent stale or invalid header construction. Pools need careful integer, endianness and clock handling and should refresh immediately when the previous block changes.
Submission abbreviations
The specification allows abbreviated results such as submitting coinbase-related data when the server can reconstruct the rest from a work identifier. This reduces transfer but introduces state coupling. A failover server cannot necessarily reconstruct another server’s abbreviation, and expired work must be rejected clearly rather than attached to a new template.
Security and trust boundary
getblocktemplate lets a miner inspect transaction selection and block rules more directly than opaque work distribution, yet the node serving templates remains consensus-critical. Protect RPC authentication and network exposure, isolate proposal traffic, validate required transactions and monitor reject reasons without logging credentials or full sensitive payloads.
Integration rehearsal
Against regtest, request the supported capabilities, propose valid and deliberately invalid candidates, exercise each permitted mutation and submit abbreviations with correct, wrong and expired work IDs. Simulate a tip change and pool failover. Record whether every backend rejects stale or unauthorised changes consistently.
Frequently asked questions
What is BIP 23 getblocktemplate for Pooled Bitcoin Mining?
BIP 23 extends BIP 22 getblocktemplate for pooled mining. It defines optional capabilities for proposing candidate blocks, declaring allowed mutations, narrowing nonce and time ranges and abbreviating submissions.
Is BIP 23 getblocktemplate for Pooled Bitcoin Mining active or supported today?
Its status is Deployed, but each extension is optional, so miners and pools must negotiate and test the exact subset rather than treating BIP 23 as one indivisible feature flag.
Why does BIP 23 getblocktemplate for Pooled Bitcoin Mining matter?
BIP 23 gives pooled miners a richer, testable getblocktemplate contract. Safe deployment depends on explicit capability negotiation, strict mutation boundaries, proposal validation and failover tests for work identifiers, time and stale templates.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
BIP 23 gives pooled miners a richer, testable getblocktemplate contract. Safe deployment depends on explicit capability negotiation, strict mutation boundaries, proposal validation and failover tests for work identifiers, time and stale templates.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
On this page
Search More Guides
BIP-110 Explained: Rules, Signalling and Why It Closed
BIP-110 Explained made simple. See the main facts, costs, risks and practical checks before you make a decision.
Read article
Bitcoin Core 29.4 Release: Chainstate Disk I/O Guide
Bitcoin Core 29.4 guide covering repeated chainstate rewrites, regular compaction, LevelDB seek compaction, transaction-data lifetime and wallet sizing fixes.
Read article
Need Advice for Your Mining Setup?
Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.