Headers-first sync

Splitting the download in two is what makes a first sync practical. Bitcoin Core has worked this way since version 0.10.0, released in February 2015, which turned block fetching from a single ordered queue into a job spread across every connected peer. If you run your own node to verify your own balance, this is why the initial sync finishes in hours rather than days.

How it works

Headers-first sync begins by asking peers for headers, not for blocks.

The node sends a getheaders message carrying a block locator, a compact list of hashes that describes where it currently thinks it is. A peer answers with a headers message holding up to 2,000 headers at 80 bytes apiece, so one reply covers roughly two weeks of chain. For each header the node checks that it points at a parent it already has and that its hash meets the difficulty its nBits field claims, then it asks again from the new tip until no peer has anything newer to offer.

Only once that skeleton is in place does body download start. Because the node already knows the hash of every block it wants, it can request different stretches from several peers at the same time instead of queueing behind one connection. Bitcoin Core limits how many block requests it leaves outstanding with any single peer, sixteen in the current code, and disconnects a peer that stalls the window. Blocks that arrive before their parents are simply held, which retired the old habit of parking unverified data on disk.

Two safeguards travel with the headers. The software will not commit to a chain until the headers it holds add up to more accumulated proof of work than a minimum figure compiled into the release, so a peer cannot lure a fresh node onto a cheap side chain made of easy blocks. Separately, the assumevalid setting names a recent block hash that ships with each version: signatures inside blocks buried under it are not re-checked, which removes hours of elliptic curve maths while every rule that depends on current chain state is still enforced.

Where you see it

Headers-first sync shows up as two counters that disagree while a node catches up.

Call getblockchaininfo during a first sync and the headers field will sit far ahead of the blocks field, often by hundreds of thousands. The graphical client says the same thing in plain language: it can only estimate a finishing time after the headers have arrived, because until then it does not know how far it still has to travel. Watching those two numbers converge is the honest progress bar.

Light software deliberately stops after the first half. An SPV wallet, a compact filter client, or a Lightning node running without its own chain backend keeps headers only and layers merkle proofs or filters on top of them. That is the whole reason a phone wallet can check its own history over mobile data: headers are small and a fixed size, block bodies are neither.

Headers-first sync vs blocks-first sync

Headers-first sync learns the shape of the chain before downloading its contents, while blocks-first sync tried to do both at once. The older method sent a getblocks message, received an inv listing no more than 500 block hashes, and pulled them one at a time from whichever peer replied, so a single slow connection throttled everything behind it. Anything arriving out of order had nowhere to live except a holding pool in memory that an attacker could stuff with junk. Bitcoin Core has not synced that way since 0.10.0, although it still understands the messages so older software can talk to it.