The block header

Wonder

1. How does a mere 80-byte structure cryptographically commit to millions of dollars in transaction data?
2. What specific rules prevent a miner from manipulating the timestamp field to gain an advantage?
3. Why can a smartphone verify the security of the Bitcoin network without downloading its entire history?

Explore

1. Every Bitcoin block begins with an 80-byte header, followed by a variable-length list of transactions. While the transaction list can reach up to approximately four million bytes per block, only the header is used for proof-of-work hashing and chain identification. This extreme size disparity means the header acts as a compact fingerprint for the entire container, allowing nodes to process metadata before downloading the bulk data.
2. The first field is ‘version,’ occupying four bytes. Originally intended to track software iterations, it now carries signaling bits for soft forks under BIP9. Miners set specific version numbers to indicate support for new consensus rules before activation. This field also includes constraints; for instance, BIP34 required version-2 blocks to embed the block height in the coinbase transaction script, demonstrating how the header enforces structural changes across the network.
3. The ‘previous block hash’ (32 bytes) links each block to its parent by containing the double SHA-256 hash of the prior header. Changing any single byte in a past block alters its hash, which breaks the link to every subsequent block. This chain of hashes ensures that historical data cannot be altered without redoing the computational work for all following blocks.
4. The ‘Merkle root’ (32 bytes) serves as a cryptographic fingerprint for all transactions within the block. It is derived by recursively hashing pairs of transaction IDs until a single value remains. This structure enables simplified payment verification, where a light client can prove a specific transaction’s inclusion using only this root and a small set of sibling hashes, rather than downloading the full block.
5. The ‘timestamp’ (4 bytes) records creation time in Unix epoch seconds. Consensus rules restrict this field to prevent manipulation: it must exceed the median time of the previous 11 blocks and is rejected by a node if it is more than two hours ahead of that node’s own clock (since Bitcoin Core 27, the node’s system time; earlier versions used a time adjusted by peers). These constraints ensure that block times remain reasonably accurate for difficulty calculations while allowing some variance due to network propagation delays.
6. The remaining fields are ‘nBits’ (4 bytes), a compact encoding of the proof-of-work target, and ‘nonce’ (4 bytes), an arbitrary number miners vary to find a valid hash. Because headers are small, storing every header since 2009 requires less than 100 MB of storage. A light client can hold this entire history, verify all proof-of-work constraints independently, and assume, without checking the transactions, that the chain with the most cumulative work is valid.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Bitcoin Developer Reference: Block Headers
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 11
• BIP9: Version bits-based consensus signalling (GitHub)