Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Blocks

A block is a header plus an ordered transaction vector. The header commits to the previous block header, transaction Merkle root, timestamp, target encoding, and nonce. The transaction vector begins with exactly one coinbase transaction.

Block header

A serialized BlockHeader is exactly 80 bytes in the field order shown:

FieldTypeEncodingMeaning
versionint324 little-endian bytesBlock version. Version bits use the high-bit pattern defined by BIP 9.
previous BlockHashuint25632 bytesDouble-SHA256 hash of the previous block header in protocol byte order.
merkleRootuint25632 bytesMerkle root of transaction identifiers. Witness data is committed separately.
timeuint324 little-endian bytesMiner-supplied Unix timestamp.
bitsuint324 little-endian bytesCompact proof-of-work target encoding.
nonceuint324 little-endian bytesNonce varied during proof-of-work search.

For a block $B$, $bh(B)=bh(B.header)$.

Block record

FieldTypeEncodingMeaning
headerBlockHeader80 bytesSerialized block header.
txCountcompactSizeCompactSizeNumber of serialized transactions.
transactionsvector< Transaction>transaction encodings in orderFirst transaction must be coinbase; all later transactions must not be coinbase.

When witness data is present, block serialization includes each transaction’s witness serialization for relay and block-weight computation. The transaction identifier Merkle root continues to use txid, not wtxid.

Merkle root

For a block transaction vector $[tx_0,…,tx_n-1]$, define:

$$ L = [txid(tx_0), txid(tx_1), \ldots, txid(tx_{n-1})]. $$

A block commits to $MR(L)$. A block with empty $L$ is invalid.

During root computation, a node rejects the duplicated-subtree mutation case: if two identical hashes are paired at a level before an odd-last duplication step, the block is invalid as mutated (sources: bitcoin-core-v31).

Coinbase transaction

The first transaction in each block is the coinbase transaction. It is the only transaction permitted to have a null prevout. No other transaction in a block may be coinbase. The coinbase creates the block subsidy and collects transaction fees; its total output value must not exceed subsidy plus fees when the block is connected.

$Rules(N,C,h,t)$ determines whether the candidate height must be serialized at the beginning of the coinbase scriptSig (sources: bip-0034,bitcoin-core-v31).

Witness commitment

If $R=Rules(N,C,h,t)$ includes SegWit and any transaction has witness data, the coinbase must commit to the witness Merkle root. The witness tree leaves are:

$$ W = [0^{256}, wtxid(tx_1), \ldots, wtxid(tx_{n-1})]. $$

The coinbase input witness contains a 32-byte reserved value $r$. The witness commitment is:

$$ wc = \mathrm{H}(\mathrm{MR}(W) || r). $$

The commitment appears in a coinbase output whose script begins with the SegWit commitment header. If multiple outputs match, the highest-index matching output is used (sources: bip-0141).

Context-free block checks

CheckRule
Transaction countThe block contains at least one transaction.
Transaction count weighttxCount * WITNESS_SCALE_FACTOR <= MAX_BLOCK_WEIGHT.
Coinbase positionTransaction zero is coinbase; no later transaction is coinbase.
Merkle rootHeader merkleRoot equals $MR(L)$ and is not mutated.
Stripped sizestrippedSize(block) * WITNESS_SCALE_FACTOR <= MAX_BLOCK_WEIGHT.
Transaction validityEvery transaction passes context-free transaction checks.
Legacy sigopslegacySigOps(block) * WITNESS_SCALE_FACTOR <= MAX_BLOCK_SIGOPS_COST.

Contextual block checks

For a candidate block at height $h$ extending chain $C$, the previous block is $C[h-1]$, and $R=Rules(N,C,h,time)$.

CheckRule
Previous headerThe previous header exists and is valid for extension.
Median timetime is greater than $MTP(C,h-1)$.
Future timeA node does not accept the block while time is more than MAX_FUTURE_BLOCK_TIME after the node’s current clock time; this is temporary future status, not permanent consensus invalidity.
BIP94 timewarpOn networks enforcing BIP94, the first block of each difficulty-adjustment interval except genesis must have time >= previous.time - BIP94_TIMEWARP_GRACE.
Difficultybits encodes the target required for the height and network.
FinalityAll transactions satisfy $AbsFinal(tx,h,t)$, where $t=MTP(C,h-1)$ if $R$ includes BIP113 and the candidate block time otherwise.
Coinbase heightIf $R$ includes BIP34, the block commits to the correct height in the coinbase.
Witness commitmentIf $R$ includes SegWit and the block has witness data, the block contains the correct coinbase witness commitment.
WeightBlock weight is at most MAX_BLOCK_WEIGHT.

The timestamp checks above follow the active validation predicates for median time past, future-time acceptance, and BIP94 timewarp mitigation (sources: bitcoin-core-v31,bip-0094).