Every block starts with an 80-byte header. Miners hash only this header, over and over, so it has to commit to everything in the block.
The six fields
- Version (4 bytes): also used for soft-fork signalling via version bits (BIP9).
- Previous block hash (32 bytes): links to the parent, forming the chain.
- Merkle root (32 bytes): commits to every transaction.
- Time (4 bytes): Unix timestamp. It must be greater than the median of the previous 11 blocks, and nodes reject blocks more than 2 hours ahead of their own clock.
- nBits (4 bytes): the difficulty target in compact form.
- Nonce (4 bytes): the number miners change.
The hash
The block hash is SHA-256 applied twice to the header. A block is valid only if that hash, read as a number, is at or below the target. This is why block hashes start with many zeros.
Not enough nonce
The nonce only has about 4.3 billion values, and modern ASICs exhaust that in a fraction of a second. Miners also change the timestamp, the version bits, and the extraNonce in the coinbase transaction. Changing the coinbase changes the Merkle root, giving a fresh search space.
The Merkle tree
The transaction txids are hashed in pairs, then the results in pairs, up to one root. If a level has an odd number of items, the last one is duplicated. A proof that a transaction is in a block needs only about log2(n) hashes. That is what light (SPV) wallets use.
The duplication rule caused CVE-2012-2459: two different transaction lists could give the same root. Bitcoin Core handles this by detecting such blocks.
SegWit's second tree
Witness data is not in the txid tree. Instead the coinbase includes an OP_RETURN output committing to a second Merkle root of wtxids (BIP141). So the witness is also covered by proof of work.
Headers-first
Because headers are small, a node can download all of them (nearly a million headers, well under 100 MB) and check the proof of work before downloading blocks.