Blocks-first sync

Nobody syncs this way any more, and the reason is arithmetic. A strictly sequential download cannot use more than one peer's upload speed, and by 2015 the chain was already too large for that to finish in reasonable time. The technique survives as a fallback in the protocol and as a source of confusion in old documentation.

How it works

Status: blocks-first sync was superseded by headers-first synchronization in Bitcoin Core 0.10.0, released on February 16, 2015. The messages it used are still part of the peer-to-peer protocol and are still answered, but no current client relies on them to catch up.

The exchange was a loop between two machines. Your node sent a getblocks message carrying the hashes of blocks it already had. The peer replied with an inventory listing up to 500 block hashes that followed. Your node asked for those blocks with getdata, received them, validated each one fully, and then sent another getblocks to ask what came next. Repeat several thousand times.

Three problems came out of that design. There was no parallelism, because you could not sensibly ask a second peer for blocks you had not yet been told existed, so the whole sync moved at the speed of whichever peer you happened to be talking to. There was no way to know how far you had to go, since the chain revealed itself 500 hashes at a time, which is why old clients could not show a meaningful progress bar. And a slow or hostile peer could simply drip-feed you, with no cheap way for your node to tell that a better chain was available elsewhere.

Headers-first fixed all three by separating the cheap evidence from the expensive. Fetch and verify the chain of headers first, at 27 megabytes for the entire history as of December 2014, and you know both the shape of the best chain and its length before downloading a single transaction. Bodies can then be requested from many peers simultaneously. The side effect was that blocks began arriving out of order and being written to disk out of order, which is why the data directory created by version 0.10.0 cannot be read by anything older.

Where you see it

You will encounter blocks-first sync in documentation rather than in software.

Reference material written before 2015, including a good deal of the developer material still circulating, describes the sequential loop as though it were how bitcoin works. It is not, and pages describing an initial sync as a single-peer sequential download are simply out of date. Bitcoin Core continues to serve getblocks requests for the benefit of ancient or unusual clients, so the messages appear in packet captures and in protocol specifications.

For anyone running a node today there is nothing to configure and nothing to choose. Your client fetches headers first because every maintained implementation does.

Blocks-first sync vs headers-first sync

Blocks-first sync and headers-first sync differ in what they ask for first, and everything else follows from that. Blocks-first requested full blocks in sequence and learned the chain's shape as it went, so it discovered the best chain and downloaded it in the same slow pass. Headers-first splits the job: establish which chain carries the most proof of work using 80 bytes per block, then collect the bodies in parallel from whoever will send them. The validation applied to each block is identical under both. What changed was the order of operations, and that alone took an initial sync from weeks to hours.