Block Template

What Is a Block Template?

A block template is the pre-assembled structure of a candidate Bitcoin block. It contains a set of selected transactions from the mempool, a coinbase transaction that pays the miner, and a fully populated 80-byte block header. The miner's job is to find a nonce value that, when hashed with the header, produces a hash below the current difficulty target.

Block templates determine which transactions get confirmed on the Bitcoin network. The entity that builds the template decides what goes into the next block: which transactions are included, which are excluded, and in what order they appear. This makes template construction one of the most consequential processes in Bitcoin's architecture.

How It Works

Constructing a block template is a multi-step process that transforms a pool of unconfirmed transactions into a single candidate block ready for mining.

1. Select transactions from the mempool, ordered by ancestor fee rate (total fees divided by total virtual size of the transaction and its unconfirmed ancestors)
2. Construct the coinbase transaction with the block subsidy (currently 3.125 BTC) plus the sum of all included transaction fees
3. Build the Merkle tree from all transaction IDs, producing a single 32-byte Merkle root
4. Populate the 80-byte block header with version, previous block hash, Merkle root, timestamp, difficulty target (nBits), and an initial nonce
5. Begin hashing: increment the nonce and, when exhausted, modify the coinbase extra nonce to produce a new Merkle root

Block Header Fields

The block header is exactly 80 bytes and contains six fields that together define the candidate block:

Transaction Selection Algorithm

Bitcoin Core uses the ancestor fee rate algorithm (introduced in PR #7600) to select which transactions fill a block template. The process works as follows:

1. The mempool indexes every transaction by its ancestor fee rate: the total fees of the transaction plus all its unconfirmed ancestors, divided by their combined virtual size
2. The algorithm picks the transaction with the highest ancestor fee rate
3. It adds that transaction and all its unconfirmed ancestors (the "package") to the candidate block
4. Descendant fee rates for remaining transactions are recalculated to reflect the newly included ancestors
5. This repeats until the block weight limit of 4,000,000 weight units is reached

This algorithm is what makes Child Pays for Parent (CPFP) work: a high-fee child transaction elevates the ancestor package fee rate, pulling its low-fee parent into the block. Miners can also manually adjust transaction priority using the prioritisetransaction RPC, which modifies a transaction's effective fee for template construction purposes.

Cluster Mempool

Bitcoin Core v31.0 introduces cluster mempool, a redesign of the mempool data structure that improves template construction. Under this model, related unconfirmed transactions are grouped into clusters (bounded at 64 transactions or 101 kB). Each cluster is linearized into an optimal ordering of "chunks" sorted by fee rate. Block template construction then becomes straightforward: include chunks in decreasing fee rate order until the block is full. This replaces the ancestor fee rate heuristic with a more globally optimal selection strategy.

The getblocktemplate RPC

The getblocktemplate RPC, defined in BIP 22 and extended by BIP 23, is the standard interface through which mining software requests block templates from a Bitcoin node. It replaced the older getwork protocol in 2012 and sends the full block structure rather than just a header, giving miners the ability to inspect and optionally modify the template.

# Request a block template from bitcoind
bitcoin-cli getblocktemplate '{"rules": ["segwit"]}'

# Response includes:
# - previousblockhash: hash of the current chain tip
# - transactions: array of selected txs with fee, weight, dependencies
# - coinbasevalue: maximum allowed coinbase output (subsidy + fees)
# - bits: compact difficulty target
# - height: target block height
# - weightlimit: 4000000 (weight units)
# - default_witness_commitment: SegWit commitment for coinbase

The response includes a mutable array listing what the miner may change: typically the timestamp, coinbase data, and transaction set. BIP 23 added a "proposal" mode that lets miners submit a fully constructed block for the pool to validate before actual mining begins.

Since BIP 145, the segwit rule must be specified in the request. The response then includes witness data for each transaction and a default witness commitment that the miner must include as a coinbase output.

Who Builds the Template

One of the most important questions in Bitcoin mining is who controls block template construction. The answer depends on which mining protocol is in use.

Stratum V1: Pool-Controlled Templates

Under Stratum V1, the dominant mining protocol since 2012, the mining pool builds the block template. The pool runs a full node, calls getblocktemplate, selects transactions, constructs the coinbase, and distributes work to miners. Individual miners hash against the template they receive with no input on transaction selection. This concentrates transaction selection power in a small number of pool operators.

Stratum V2: Miner-Selected Templates

Stratum V2 introduces an optional Job Negotiation Protocol that allows individual miners running their own full nodes to construct block templates from their own mempools. The miner proposes a template to the pool, which validates it and attributes the work. This decentralizes transaction selection back to individual miners.

Additional improvements in Stratum V2 include encrypted communication (preventing hashrate hijacking), approximately 60-70% bandwidth reduction, and block switching latency reduced from roughly 325 milliseconds to under 2 milliseconds. As of mid-2026, pools representing approximately 75% of global hashrate have joined the Stratum V2 Working Group.

Why It Matters

Block template construction sits at the heart of Bitcoin's security model. The template determines which transactions get confirmed, how quickly the mempool clears, and whether the network remains censorship-resistant. For a deeper analysis of how fees and template economics interact, see the Bitcoin fee market dynamics research article.

For layer-2 protocols like the Lightning Network and Spark, block templates matter because on-chain settlement transactions must eventually be included in a block. Time-sensitive transactions such as justice transactions, channel closes, and HTLC timeouts depend on predictable block inclusion. Understanding how templates are constructed helps developers set appropriate fee rates and timeouts for these critical transactions.

For miners, template optimization directly affects revenue. Selecting the highest-fee transactions within the weight limit maximizes the fees collected in each block. The mining economics in 2026 research article explores how the declining block subsidy makes transaction fee revenue increasingly important.

Risks and Considerations

Centralization of Template Construction

Under Stratum V1, a handful of pool operators control which transactions enter virtually all blocks. If a few pools collude or are coerced by regulators, they could censor specific transactions. This centralization risk is a primary motivation behind Stratum V2's miner-selected template feature and projects like the Stratum Reference Implementation (SRI).

MEV and Front-Running

Miner Extractable Value (MEV) describes profits miners can capture by manipulating transaction ordering within their templates. While historically minimal on Bitcoin due to the simplicity of UTXO transactions, the rise of metaprotocols like Ordinals and BRC-20 tokens has introduced new front-running vectors. Capped minting operations create race conditions where bots scan the mempool and submit competing transactions with higher fees.

Out-of-Band Fee Payments

Transaction accelerator services allow users to pay mining pools directly (via Lightning or fiat) to prioritize specific transactions. While convenient for users, these out-of-band payments create fee revenue invisible to other nodes' fee estimation algorithms. This can undermine the transparency of Bitcoin's fee market and potentially its censorship resistance.

Template Staleness

When a new block is found on the network, all current templates become stale: they reference an outdated previous block hash. Miners must quickly switch to a new template or risk mining an orphaned block. Under Stratum V1, this switch takes roughly 325 milliseconds on average. Stale templates waste hashrate and reduce miner revenue, making low-latency template updates a competitive advantage. Stratum V2 reduces this latency to under 2 milliseconds.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.