Block Template

Each new block builds on a particular predecessor. The template identifies it through previousblockhash, its unique fingerprint, while height gives the position of the proposed block in the chain. Other fields include version, the header version; bits, a compact encoding of the target for the mining result; and time information. These are instructions for assembling a particular block, not an independent payment list. The same transactions placed after a different predecessor already make a different assignment. [1]

Anna receives bitcoin and then pays with it. If both transfers are to appear in the same block, the transaction assigning her those funds must come before the one spending them. BIP 22, the technical document describing the template format, defines the depends field for these relationships: it refers to earlier entries using one-based positions in the transactions list. That list excludes coinbase, the special first transaction assigning the miner’s reward. A missing depends field means unknown dependencies, not confirmation that none exist. Software must not assume the missing information means an empty list. [1]

The reward includes newly issued bitcoin under the rules for that block height and fees from transactions actually included. The referenced Bitcoin Core v29.0 assembles it this way too. This software verifies blocks and transactions and can also prepare mining templates. In our own example, transactions contribute 10000 sats; removing an independent transaction paying 3000 sats leaves 7000 sats in fees. Sats are small units of bitcoin. The coinbasevalue field gives the maximum reward the miner may claim for the original transaction selection. After changing that selection, the amount must be recalculated. The calculation must use actual fees, not a total worked out for the old contents. [4] [1]

A block also contains cryptographic fingerprints that let its data be checked. BIP 141 describes the witness commitment, a binding fingerprint of witness data, which includes items such as signatures proving spending authorization. It is derived from wtxid identifiers that include this data. Bitcoin Core 29 supplies default_witness_commitment for an unchanged template. After relevant transactions or their order change, the commitment must be checked or recalculated. The Merkle root, the combined transaction fingerprint in the header, must also be calculated from the final TXID identifiers, including that of the modified coinbase. An old seal does not belong on changed contents. [5] [3]

Block space is limited, and miners choose what to include. Bitcoin Core v29.0 considers packages of related transactions, their weight, a measure of data load, and sigops, the signature-checking operations counted towards the block limit. Settings such as blockmaxweight and blockmintxfee influence the assembled block’s size and the required fee rate. This is selection policy. A payment omitted for that reason is not necessarily invalid under network rules. A miner’s settings also cannot raise the network limits enforced by other nodes. [4] [3]

In BIP 23, mutable lists changes the server permits, such as adjusting time or adding transactions. It is an agreement about working with a particular template. Server permission does not override consensus, the validity rules independently checked by other network participants. The predecessor, time, difficulty and transactions must still be correct. Access to a template also does not mean every connected mining device can change its contents freely; that depends on the setup and the job it receives. [2]

Another miner may extend the chain while calculations are underway. To continue working on top of the latest accepted block, simply replacing the predecessor’s fingerprint in the old template is not enough. Some transactions may already be confirmed, and the height and other conditions change. BIP 23 describes expires as a work time limit and prevblock as permission to use that work with a different predecessor. Even this permission does not replace validation: transactions, the reward and the whole new context must be reassessed. [2]

It is better to catch a mistake in a proposed block before a long search. The proposal mode in BIP 23 allows a draft to be checked without requiring valid Proof of Work, a result already demonstrating the necessary computational work. A positive assessment does not mean a block has been found, broadcast or guaranteed a permanent place in the chain. It means the draft passed the relevant preliminary check. The finished block must then undergo the appropriate validation on submission, including its proof of work. [2]