Header chain

A node tracks two things at once: the headers it believes in and the block bodies it has stored. Headers weigh 80 bytes apiece, so one year of them, about 52,560 blocks, comes to roughly 4.2 MB. That size difference is why a wallet can know the chain's current height and total accumulated work long before it can tell you what is inside any particular block.

How it works

The header chain is ordered by accumulated proof of work, not by how many blocks it contains.

Every header names its parent, so the collection of headers a node has heard about forms a tree rather than a line. The branch carrying the greatest total work is the best header chain, and the node remembers the losing branches too, in case one of them later overtakes. Bitcoin Core keeps this tree in the block index, a small LevelDB database under the blocks/index directory, entirely separate from the raw block files that hold transactions.

Because the tree is kept, a node can describe its own uncertainty. The getchaintips command lists every tip it knows about with a status attached: active for the branch it is following, headers-only for a branch whose bodies were never fetched, valid-fork for a fully validated branch that lost the race, and invalid for one that broke a rule. A reorganization is nothing more than the node walking from one tip to another across that tree once it has the blocks to do so.

Headers survive things that block data does not. A pruned node deletes old block files to save space, and even at prune=550, the smallest setting Bitcoin Core accepts, it keeps every header from the genesis block onward. Without them it could not check that a new block builds on the chain it already accepted, so the headers are the part it can never throw away.

Where you see it

The header chain is the number your node quotes when it tells you how far behind it is.

Run getblockchaininfo and you get two fields, blocks and headers. Headers is the height of the best header chain, blocks is how much of it has been downloaded and fully validated, and the difference between them is the work still outstanding. On a synced node the two match, and a node whose headers value is stuck is one that has lost touch with its peers rather than one that is merely slow.

Lightweight wallets keep nothing else. An SPV wallet or a compact filter client stores headers only and uses them to confirm that a transaction it cares about sits under real proof of work. Difficulty is computable from headers too, since the target resets every 2,016 blocks using nothing but the timestamps and nBits values already in the chain, which means a client can verify that the work it is counting is genuine without ever seeing a transaction.

Header chain vs block header

A block header is a single 80 byte record; the header chain is all of them linked back to the genesis block of January 3, 2009. The distinction matters when someone says a light client verifies proof of work. One header proves that one block was expensive to produce. Only the chain of them, each committing to its parent, proves that a specific block sits behind an unbroken run of expensive work that nobody has quietly replaced.