Blocks

Block and block-header structure, serialization, and validity

A block is an 80-byte header followed by an ordered list of transactions. The header commits to the block's transactions through the Merkle root and to the previous block through its hash, linking blocks into a chain. This page specifies the exact serialization and the consensus rules that make a block's structural fields valid.

Ground truth. The layouts below derive from CBlockHeader/CBlock in src/primitives/block.h, Merkle construction from src/consensus/merkle.cpp, and proof-of-work from src/pow.cpp. All citations are pinned to release v1.2.2 (commit 879fc8b).

Block header (80 bytes)

The header is a fixed 80 bytes: six fields, in this exact order (CBlockHeader::SerializationOp, block.h L36–L46):

#	Field	Type	Size (bytes)	Encoding	Notes
1	nVersion	int32	4	little-endian, signed	Block version. Must be ≥ 2 at/after the BIP34 activation height (see Coinbase height).
2	hashPrevBlock	hash	32	internal byte order	Double-SHA-256 of the previous block's 80-byte header.
3	hashMerkleRoot	hash	32	internal byte order	Merkle root of the block's transactions (see Merkle root).
4	nTime	uint32	4	little-endian	Block timestamp (Unix epoch seconds).
5	nBits	uint32	4	little-endian	Compact-form proof-of-work target (see Proof of work).
6	nNonce	uint32	4	little-endian	Nonce varied during mining.

The block hash is the double-SHA-256 of these 80 bytes, displayed as big-endian hex. Only the header is hashed for proof of work; the transactions are bound to it through hashMerkleRoot.

Block body

A full block is the header followed by its transactions (CBlock::SerializationOp, block.h L97–L102):

#	Field	Type	Size (bytes)	Encoding	Notes
1	header	CBlockHeader	80	see above	The 80-byte header.
2	transaction count	CompactSize	1–9	little-endian	Number of transactions that follow.
3	vtx	CTransaction[]	variable	—	The transactions, back to back (see Transactions). The first transaction must be the coinbase.

The CompactSize count uses the same encoding as elsewhere in the protocol (1, 3, 5, or 9 bytes; see Transactions).

Merkle root construction

hashMerkleRoot commits to every transaction. It is built bottom-up (ComputeMerkleRoot / BlockMerkleRoot, merkle.cpp L150–L184):

1. The leaves are the transaction IDs (TxIDs), in block order.
2. At each level, adjacent nodes are paired and each pair is hashed with double-SHA-256 of the two 32-byte values concatenated.
3. If a level has an odd number of nodes, the last node is paired with itself.
4. This repeats until a single 32-byte root remains. A block with one transaction has that transaction's TxID as the root.

Mutation guard (CVE-2012-2459). Because the odd-node rule duplicates the last hash, an attacker could once craft two different transaction lists producing the same root. The builder detects any duplicated adjacent subtree hash and sets a mutated flag (mutated |= (inner[level] == h), merkle.cpp L89); a block whose Merkle computation is flagged mutated is treated as having an invalid Merkle root and is rejected. The calculator is limited to 2³² leaves.

Coinbase height (BIP34)

At and after the BIP34 activation height, the coinbase transaction's scriptSig must begin with the block height, serialized as a Script number push. The node builds the expected prefix as CScript() << nHeight and requires the coinbase scriptSig to start with exactly those bytes (validation.cpp L6039–L6048); a mismatch is rejected as bad-cb-height. From the same height, blocks with nVersion < 2 are rejected.

Proof of work

A block header is valid under proof of work when its hash meets the target encoded in nBits (CheckProofOfWork, pow.cpp L150–L171):

1. Decode nBits from its compact form to a 256-bit target.
2. Reject if the target is negative, zero, overflows, or exceeds the chain's powLimit (the maximum/easiest allowed target).
3. Require blockHash ≤ target (both interpreted as 256-bit big integers).

nBits itself must equal the value required by the difficulty-adjustment algorithm for that height (GetNextWorkRequired, pow.cpp L95). BSV's history here is: the original retarget, then the Emergency Difficulty Adjustment (EDA) introduced at the UAHF fork, replaced by the current Difficulty Adjustment Algorithm (DAA) at the daaHeight (mainnet 504,031), which retargets each block from a 144-block window. Target block spacing is 10 minutes. The details of how the next target is computed are consensus (they determine whether a block's nBits is valid); the mining machinery that searches for a nonce is not part of the protocol.

Block size by era

Rule	Pre-UAHF	UAHF → Genesis	Genesis onward
Maximum block size	LEGACY_MAX_BLOCK_SIZE = 1,000,000 bytes (1 MB), consensus (consensus.h L31)	raised, miner-configurable consensus cap	miner-configurable consensus cap (no fixed protocol maximum)

From the UAHF onward the block-size limit became a value miners set rather than a single hard-coded constant. There is a consensus limit at any moment (a block exceeding the active cap is invalid); the specific number a node uses is an operator-chosen policy value (e.g. MAIN_DEFAULT_MAX_BLOCK_SIZE) and is not itself part of the validity contract. See Protocol Upgrade History for the activation timeline.