Glossary / Mining & consensus
Block header
Also known as Header.
- Definition
- A block header is the 80 byte summary of a block: version, previous header hash, merkle root, timestamp, nBits, and nonce, and it is the part miners actually hash.
Miners never hash the payments directly. They hash this fixed size record, which commits to the transaction list through the merkle root and to every earlier block through the previous header hash. Eighty bytes per block is small enough that the complete header chain since January 2009 fits comfortably on a phone, and that fact is what makes lightweight verification possible at all.
How it works
A block header is six fields in a fixed order, and their byte offsets never move.
Version occupies bytes 0 to 3. The previous block header hash takes bytes 4 to 35. The merkle root takes bytes 36 to 67. The timestamp, in seconds since the Unix epoch, sits at bytes 68 to 71. nBits, the encoded difficulty target, sits at bytes 72 to 75. The nonce fills bytes 76 to 79. Every field is stored little endian, which is why the hex you see in an explorer looks byte reversed compared with the hex in a raw block dump.
The block hash is not one of those fields. It is computed by running SHA-256 twice over the 80 bytes, and nodes derive it rather than trust it, which is precisely why a block cannot lie about its own identity. Proof of work is the same operation with a comparison attached: the resulting number has to be at or below the target that nBits encodes.
Two of the fields carry rules that surprise people. The timestamp does not have to be accurate. It only has to exceed the median timestamp of the previous eleven blocks and stay within two hours of the receiving node's own clock, so headers with slightly out of order times are ordinary and valid. The version field is no longer a simple counter either. Soft fork signalling under BIP9 and version rolling under BIP320 both borrow bits from it, so a version number in a modern header is a bit field rather than a release number.
Where you see it
Block headers are the first thing a new node downloads and the only thing many wallets keep.
Bitcoin Core has synced headers first since version 0.10, released in February 2015. The node fetches and validates the header chain, confirms it carries real proof of work, and only then requests block bodies, which it can do from several peers in parallel because it already knows what it is looking for. Light clients stop at that first step: an SPV or Neutrino wallet keeps headers and checks that a transaction's merkle branch connects to one of them. At 80 bytes each, a chain of 900,000 headers is 72 MB, which is why this works over mobile data.
The genesis header is the canonical example to inspect. Its version is 1, its previous header hash is all zeros, its merkle root is 4a5e1e4b and so on, its timestamp is 1231006505, which is January 3, 2009, its nBits value is 0x1d00ffff, and its nonce is 2083236893. You can hash those 80 bytes yourself and get the familiar block hash beginning with ten zeros. If you want to see any other header, the Bitcoin Core RPC getblockheader returns exactly these fields and nothing else.