Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Node Operations

Initial Block Download

A node that has just been installed knows nothing. Before it can tell you anything useful, it has to download every block since the genesis block and check each one against the consensus rules. That process is called initial block download, and it is deliberately slow.

Last reviewed 2026-09-21Source: Bitcoin Core initial block download documentation; Bitcoin whitepaper (Nakamoto, 2008)Operational guidance for node software evolves; the behaviour described is that of current Bitcoin Core releases.

What the process does

Initial block download begins with the node connecting to a set of peers and asking them for the block headers they know about. Headers are small, so the node can assemble a candidate chain quickly. It then walks that chain from the genesis block forward, requesting each block in turn and validating it before moving on. A block is accepted only if it satisfies every consensus rule the node enforces.

The validation is not a formality. For each block the node checks the proof of work against the difficulty target, verifies that the transactions are well formed, confirms that each input spends an output that exists and has not already been spent, checks the signatures, and confirms that the block's coinbase transaction claims no more than the subsidy plus the fees it collected. A block that fails any of these checks is rejected, and the node does not build on it.

The result is a chain the node has verified itself, from the first block to the tip. That is the difference between holding a copy of the chain and holding a copy you have checked. A node that has completed the download can answer questions about balances and confirmations on its own authority, rather than by trusting whoever supplied the data.

Why it is slow

The download is slow because the validation is the point. A node could accept the chain on a peer's word and be usable in minutes, but it would then be trusting that peer rather than checking the chain. The design chooses verification over speed, and the cost is that the first sync takes hours or days depending on the hardware and the connection.

The signature checks are the most expensive part. Every input in every transaction carries a signature that has to be verified, and the chain contains hundreds of millions of inputs. Modern hardware verifies them far faster than the hardware of 2009 could, which is why the sync is now measured in hours rather than weeks, but the work is still substantial and it is still done one block at a time.

The node also has to write the validated blocks to disk, and the order of operations matters: a block is validated before it is stored, so the disk write cannot be parallelised ahead of the verification. The bottleneck moves between the network, the CPU and the disk depending on the machine, which is why two nodes on the same connection can take very different amounts of time.

What happens afterwards

Once the download completes, the node switches to keeping up with new blocks as they are found. The work per block is the same, but it arrives roughly every ten minutes rather than in a continuous stream, so the node is idle most of the time. It uses that idle capacity to serve blocks and transactions to other nodes, which is how the network distributes data without a central server.

The node also begins maintaining a mempool, the set of unconfirmed transactions it has accepted under its own relay policy. That policy is covered on the mempool policy page, and it is a separate matter from the consensus rules the node enforced during the download. A node can relay a transaction it would never accept in a block, and it can reject a transaction that would be perfectly valid if a miner included it.

The storage the validated chain occupies is covered on the storage page. It is the resource that decides whether a node can keep the whole chain or has to prune, and pruning is a choice that changes what the node can do afterwards.

Sources and references

The description of the download procedure, the validation performed and the longest-chain rule is taken from the Bitcoin Core documentation and the original whitepaper.

Related reading