A brand-new full node has to download and check every block since 2009 before it knows the current state. This is initial block download (IBD), and it is the heaviest work a node ever does.
Headers first
The node first downloads only block headers, 80 bytes each, up to 2,000 per message. It checks their proof of work and picks the chain with the most work. Bitcoin Core also requires a minimum amount of total work (nMinimumChainWork), and first checks a peer's headers before storing them, so that fake low-work chains cannot waste its memory.
Blocks in parallel
With the header chain known, the node fetches blocks from several peers at once, up to 16 in flight per peer, within a moving window of 1,024 blocks. Blocks are then connected in order. Each one updates the chainstate.
Shortcut 1: assumevalid
Checking every signature is the slowest part. Each Bitcoin Core release includes a recent block hash. With assumevalid, script and signature checks are skipped for that block and its ancestors, if it is in the chain being synced. Bitcoin Core 31.1 uses block 938,343. Everything else is still verified, and the UTXO set is built in full. To check every signature, start with -assumevalid=0.
Shortcut 2: assumeutxo
Instead of building the UTXO set from scratch, a node can load a snapshot with loadtxoutset. The snapshot is rejected unless its hash matches one in the source code. Bitcoin Core 31.1 lists snapshots for heights 840,000, 880,000, 910,000 and 935,000. The node is usable near the tip quickly, while it checks the full history from genesis in the background.
What makes IBD faster
- An SSD instead of a spinning disk.
- A larger
-dbcache. Since version 31.0, the default is 1,024 MiB on machines with at least 4,096 MiB of RAM. - A good network connection.
Trust
Both shortcuts rely on values that are reviewed in public in the open-source code. They do not let a node accept a chain with less work, and both can be turned off.