Block Header

What Is a Block Header?

A block header is the 80-byte metadata structure that sits at the top of every Bitcoin block. It contains the information miners hash to produce proof of work, and it links each block to its predecessor to form the blockchain. While the block body holds the actual transaction data, the header is what nodes verify to determine the chain with the most accumulated work.

Every block header commits to the entire contents of its block through the Merkle root field, which is a cryptographic summary of all transactions. This means verifying a header implicitly verifies the integrity of every transaction in that block, a property that underpins lightweight verification across the network.

The Six Fields

The block header is composed of exactly six fields, serialized in a fixed layout with no padding or optional data:

All numeric fields are encoded in little-endian byte order. Hash fields (previous block hash, Merkle root) are stored in internal byte order, which is the reverse of the hex strings displayed in block explorers.

Version

The version field is a 4-byte signed integer that indicates which consensus rules the block follows. Under BIP 9, the top three bits must be set to 001, constraining valid values to the range 0x20000000 through 0x3FFFFFFF. This leaves 29 bits available for signaling support for proposed soft forks: each proposal is assigned a distinct bit, and miners set that bit to 1 to signal readiness.

BIP 320 further refines this by reserving bits 13 through 28 (16 bits) for general-purpose use, primarily mining optimization through version rolling. These reserved bits are excluded from soft fork signaling, so miners can freely toggle them for additional hash diversity without triggering false upgrade warnings.

Previous Block Hash

This 32-byte field contains the double-SHA256 hash of the preceding block's header. It is the mechanism that chains blocks together: changing any bit in a prior block would invalidate this hash and break the chain from that point forward. The genesis block (block 0) has this field set to all zeros since there is no preceding block.

Merkle Root

The Merkle root is a 32-byte hash that cryptographically commits to every transaction in the block. It is computed by recursively pairing transaction IDs, concatenating each pair, and applying double-SHA256 until a single root hash remains. If the block contains only the coinbase transaction, the Merkle root equals that transaction's ID.

This structure allows any transaction to be verified with a Merkle proof: a path of log₂(n) sibling hashes from the transaction up to the root. An SPV client can verify a transaction's inclusion by checking this proof against the header's Merkle root without downloading the full block.

Timestamp

The timestamp is a 4-byte unsigned integer representing Unix epoch seconds. Two consensus rules constrain its value:

• It must be strictly greater than the Median Time Past (MTP): the median timestamp of the previous 11 blocks
• It must be less than the network-adjusted time plus 2 hours (7,200 seconds)

Blocks do not require monotonically increasing timestamps. A block can have an earlier timestamp than its predecessor as long as it exceeds the MTP. Because this is an unsigned 32-bit integer, the timestamp will overflow around February 2106, rather than hitting the signed 32-bit year-2038 limit.

nBits (Difficulty Target)

The nBits field encodes the 256-bit target threshold in a compact 4-byte format using base-256 scientific notation. A valid block hash must be numerically less than or equal to this target.

// nBits format: [exponent: 1 byte] [significand: 3 bytes]
// target = significand × 256^(exponent - 3)

// Example: nBits = 0x1D00FFFF (difficulty 1)
// exponent  = 0x1D = 29
// significand = 0x00FFFF
// target = 0x00FFFF × 256^(29-3) = 0x00FFFF × 256^26
// = 0x00000000FFFF00000000000000000000
//   00000000000000000000000000000000

The target is recalculated every 2,016 blocks (approximately two weeks) during the difficulty adjustment. The new target equals the old target multiplied by the ratio of actual time to expected time for the previous period, clamped to at most a 4x increase or a 4x decrease per adjustment.

Nonce

The nonce is a 4-byte unsigned integer that miners increment to search for a valid block hash. Its range of 0 to 4,294,967,295 (2³² values) was sufficient in Bitcoin's early days, but modern ASIC miners operating at over 100 TH/s exhaust the entire nonce space in microseconds.

How Mining Uses the Block Header

Mining is the process of repeatedly hashing the 80-byte block header (using double-SHA256) and checking whether the resulting hash falls below the current target. Each attempt requires changing at least one field in the header to produce a different hash.

1. The miner assembles a candidate block with a valid block template and computes the Merkle root
2. The miner serializes the 80-byte header and begins hashing with nonce = 0
3. If the resulting hash exceeds the target, the miner increments the nonce and tries again
4. If the hash is below the target, the block is valid and the miner broadcasts it to the network

The ExtraNonce and Expanded Search Space

When the 4-billion-value nonce space is exhausted without finding a valid hash, miners must change another field in the header to reset their search. The standard approach is modifying the extraNonce: arbitrary data stored in the coinbase transaction's scriptSig. Changing the coinbase transaction changes its TXID, which propagates up the Merkle tree and produces a new Merkle root in the header.

Miners typically allocate 8 bytes of extraNonce space within the coinbase scriptSig, which combined with the 4-byte nonce provides 2⁹⁶ total combinations. Additional dimensions include rolling the timestamp (incrementing by one second) and version rolling under BIP 320, where 16 bits of the version field can be freely toggled for even more hash diversity.

Version Rolling and ASICBoost

ASICBoost is a mining optimization that exploits the structure of the SHA-256 compression function. The "overt" variant works by varying bits in the version field, which occupies the same SHA-256 message chunk as the previous block hash. BIP 320 formally reserves 16 bits (bits 13 through 28) for this purpose, and the Stratum protocol's version-rolling extension lets miners negotiate which bits to use with their pool.

Why It Matters for SPV

The block header's fixed 80-byte size makes Simplified Payment Verification practical for resource-constrained devices. An SPV client downloads only block headers, not full blocks. At 80 bytes per block with approximately 52,560 blocks per year, the header chain grows by roughly 4.2 MB annually. The entire header chain since the genesis block in 2009 totals around 75 MB, compared to over 600 GB for the full blockchain.

To verify that a transaction was included in a block, an SPV client requests a Merkle proof from a full node: the path of sibling hashes connecting the transaction's TXID to the block header's Merkle root. The client then verifies that this header belongs to the chain with the most accumulated proof of work. Compact block filters (BIP 157/158) improve on this model by allowing clients to query for relevant transactions without revealing which addresses they control.

For a deeper look at how lightweight clients leverage headers, see Bitcoin Light Clients: SPV Explained.

Version Bits Signaling for Soft Forks

The version field serves as the coordination mechanism for activating soft fork upgrades. BIP 9 defines a state machine with five states for each proposed upgrade:

1. DEFINED: the proposal exists but its start time has not arrived
2. STARTED: miners can signal support by setting the assigned bit to 1
3. LOCKED_IN: at least 95% of blocks in a 2,016-block retarget period signaled support (1,916 of 2,016)
4. ACTIVE: the new rules are enforced after one additional retarget period
5. FAILED: the timeout expired without reaching LOCKED_IN, and the bit can be reused

BIP 8 extended this model with a "lock-in on timeout" (LOT) parameter, allowing a soft fork to activate at timeout even without 95% miner signaling. Taproot (BIP 341) used this mechanism through the Speedy Trial deployment. Notable earlier deployments include SegWit (bit 1) and the CSV timelocks (bit 0).

Use Cases

The block header's compact structure serves several critical roles across the Bitcoin ecosystem:

• Chain validation: full nodes verify the proof-of-work chain by checking that each header's hash meets its target and that the previous block hash links correctly
• Lightweight wallets: SPV clients and mobile wallets download only headers to verify payments, enabling Bitcoin on resource-constrained devices
• Mining coordination: the header's fields (nonce, version bits, timestamp) define the search space that mining pools distribute across workers
• Protocol upgrades: version bits signaling allows the network to coordinate soft fork activation without hard forks or centralized decision-making
• Cross-chain verification: protocols like Spark and other Layer 2 systems reference block headers to anchor off-chain state to Bitcoin's proof-of-work security

Risks and Considerations

Timewarp Attack

Because timestamps only need to exceed the Median Time Past of the previous 11 blocks, a miner controlling a majority of hashrate could manipulate timestamps at difficulty adjustment boundaries to artificially lower the difficulty. In the worst case, this could allow all remaining block subsidy to be mined in approximately 40 days. BIP 54 (Consensus Cleanup) proposes fixing this by constraining timestamps at retarget boundaries.

Merkle Tree Vulnerabilities

The Merkle tree construction has a known quirk: when there is an odd number of items at any level, the last item is duplicated. This means two different transaction lists can produce the same Merkle root (CVE-2012-2459). Additionally, a carefully crafted 64-byte transaction could mimic an internal Merkle tree node, potentially fooling SPV clients into accepting invalid Merkle proofs. BIP 54 addresses this by making all 64-byte transactions invalid at the consensus level.

Year 2106 Overflow

The 4-byte unsigned timestamp will overflow around February 2106. While this is far enough away that no immediate action is required, it represents a hard limit in the current header format that will eventually need a consensus-level resolution.

Nonce Space Limitations

The 4-byte nonce was designed when CPU mining was the norm. Modern ASICs exhaust it in microseconds, requiring constant Merkle root recalculation via extraNonce changes. This adds latency and complexity to mining operations, though version rolling (BIP 320) helps by providing additional bits to vary without rebuilding the Merkle tree.

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.