Initial block download

This is the one genuinely slow part of running your own node, and it happens once. The node has 759 GB of history to collect and check as of August 2026, which takes hours on a fast machine with a solid state drive and days on a weak one. Bitcoin Core knows it is finished when its tip is less than 24 hours old and the chain it holds carries enough accumulated work.

How it works

Initial block download is deliberately front-loaded with the cheapest evidence.

Headers come first. Since version 0.10.0, released on February 16, 2015, Bitcoin Core asks peers for the chain of 80 byte block headers before requesting any block bodies. Verifying those headers is quick, it establishes which chain has the most proof of work, and it means the software knows in advance how many blocks it is looking for. Blocks can then be requested from several peers in parallel instead of one at a time, which is the difference between a sync measured in hours and one measured in weeks.

Signature checking is the expensive part, so there is a shortcut with a switch on it. Bitcoin Core 0.14.0 introduced a setting that names a specific historic block, hardcoded into each release after review, and skips script signature verification for everything buried beneath it. Every other rule still applies: amounts, double spends, subsidies, merkle roots, proof of work. Set the option to zero and the node checks every signature since 2009, which is worth doing once if you want to trust nothing at all.

There is now a way to be useful before you are finished. Bitcoin Core 28.0 shipped parameters for loading a snapshot of the unspent output set taken at block height 840,000, letting a node serve your wallet within minutes while it quietly rebuilds the earlier history behind the scenes. When the background sync reaches the snapshot height it compares its own computed hash against the one in the release; a mismatch shuts the node down.

Memory is the lever most people never pull. The database cache defaults to 450 mebibytes, and raising it to several gigabytes on a machine with the spare capacity keeps the unspent output set in RAM instead of thrashing the disk, cutting hours off the total.

Where you see it

You meet initial block download the first time you start Bitcoin Core, and again after leaving a node switched off for months.

The interface will tell you it is synchronizing headers, then report how many weeks behind it is, and the estimate is unreliable early on because blocks from 2011 are tiny and blocks from last year are not. Progress is not linear, and a node that appears stuck at 60 percent is usually working through the heaviest years of the chain.

Three practical rules cover almost everything that goes wrong. Use a solid state drive, because a spinning disk turns a one day job into a one week job. Give the process bandwidth and a stable connection, since the whole archive has to arrive. And do not attach a wallet and panic about a missing balance until the sync has actually finished, because a partially synced node has no opinion about coins in blocks it has not reached yet.

Initial block download vs blocks-first sync

Initial block download is the goal; blocks-first sync was one obsolete way of reaching it. The distinction matters when reading older documentation, which often describes the two as though they were the same thing. Any node catching up performs an initial block download, whether it does so by requesting blocks sequentially from a single peer, by fetching headers first and then pulling bodies from many peers at once, or by loading a snapshot and backfilling. The phase has a name because it has different performance characteristics and different attack surface from steady-state operation, not because it prescribes a method.