Initial block download

Wonder

1. Why does a new node download block headers before it downloads any blocks?
2. What specific checks are skipped when ‘assumevalid’ is enabled, and why is that safe?
3. If bandwidth is fast enough to fill a drive in minutes, why can initial sync still take days?

Explore

1. A fresh Bitcoin Core instance contains only the genesis block, hard-coded into its source. It knows nothing of the chain’s length or validity. Upon connecting to peers, it initiates Initial Block Download (IBD), a process that reconstructs the entire history from January 3, 2009, to the present tip. This is not a passive copy; it is an active reconstruction where each block is checked against the consensus rules, apart from the shortcuts described below, before it is accepted.
2. Since version 0.10 (2015), IBD follows a two-phase strategy. First, the node downloads all block headers, which are compact and fast to transmit. It verifies the proof-of-work on these headers to confirm they meet the difficulty target, building a chain of work without yet checking transaction validity. Once the header chain is established, the node requests full blocks from multiple peers in parallel, validating them sequentially as they arrive.
3. Transaction validation is computationally expensive due to cryptographic signature checks. To accelerate sync, version 0.14 (2017) introduced ‘assumevalid’. This parameter skips signature verification for all blocks buried beneath a hard-coded hash of a widely reviewed block. The node still checks everything else, including proof of work, amounts and the UTXO set; only script and signature checks are skipped for that deep history. Users can disable this check to verify every single signature from genesis, at the cost of significantly longer sync times.
4. Recent versions offer ‘assumeUTXO’, an experimental feature allowing a node to start with a pre-computed snapshot of the current UTXO set. The node becomes usable quickly while it verifies the full history in the background. Until that check finishes, it trusts a snapshot whose hash is hard-coded in the software (the file itself can come from anywhere); afterwards it is fully independent.
5. The duration of IBD varies wildly with hardware. On a modern machine with a fast SSD and 8 GB of RAM, sync may take hours. On constrained devices such as a Raspberry Pi, it can take several days or longer. The bottleneck is rarely bandwidth; it is disk write speed for the UTXO cache (dbcache) and CPU cycles for script validation. A slow hard drive will stall the process even with gigabit internet, as the node must constantly read and write state.
6. Once synchronized, the node reaches the tip of the most-work valid chain. It transitions from an observer to a full participant, capable of relaying transactions and blocks to its peers. The `bitcoin-cli getblockchaininfo` command reveals this progress via the `verificationprogress` field, which climbs toward 1.0 as the historical chain is validated. At that point, the node holds a complete, independently verified copy of the money’s history.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Bitcoin Core Release Notes 0.10.0 (2015)
• Bitcoin Core Release Notes 0.14.0 (2017)
• Bitcoin Core Documentation: 'assumeutxo.md'
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)