Initial Block Download

You start a Full Node at home: software that independently checks Bitcoin blocks and transactions. A block groups transactions into a batch added to the shared history. Other participants already have a long history behind them; your new node has none of it yet. It first obtains headers, compact records linking blocks together. They also contain Proof of Work, evidence of computational work. Miners find this proof through repeated calculations; others can quickly check the result. Think of the headers as a book’s contents page: it helps you find your way, but having it does not mean you have read and checked every page. [1] [7]

If peers offer different branches of history, the node does not count votes. Headers let it compare accumulated computational work and select a promising candidate for further validation. More blocks do not necessarily mean more work. Even a large amount of work gives invalid transactions no exemption from the rules; the chosen branch’s contents still need checking. [1] [2] [6]

The node can obtain blocks from several peers at once, avoiding dependence on a single sender’s speed. To connect them to its validated history, however, it needs the preceding state. A payment’s inputs refer to earlier amounts it intends to spend. The node must establish that these amounts exist and have not already been spent. A later block already on disk may therefore wait for an earlier one to be processed. This is one reason downloaded data are not the same as completed synchronization. [1] [2]

The node compares a block’s contents with the transaction fingerprint in its header, produced by a Merkle Tree. It also checks matters such as the chain of spending and whether the miner’s reward exceeds the permitted amount. It applies the rules that were active at that point in history. A digital signature provides proof of authorization for a payment using a private key, a secret numerical value, without revealing that key. Old signature and spending-condition checks have a special setting, assumevalid, explained below. Headers, or a file from a seemingly trustworthy peer, do not replace this body of checks. [2] [3]

As each block is processed, the node removes spent outputs and adds new ones. An output is a specific amount with conditions for spending it later. An output that remains unspent is called a UTXO. The set of these outputs lets the software check the next payment without rereading the entire history each time. It is neither a list of bank accounts nor a copy of every historical transaction. [2] [3]

Under certain conditions, Bitcoin Core can skip old script checks: checks of signatures and other spending conditions. The assumevalid setting identifies a known block whose history has been externally verified; ancestry, sufficient work and depth also matter. Other necessary checks remain, but part of the verification result is assumed. An incorrect assumption is therefore not risk-free. Setting assumevalid=0 disables this optimization at the cost of more work for your computer. [2]

A Pruned Node removes old block files after processing them, retaining the current UTXO set and other necessary data. During ordinary IBD it still obtains and processes the history; it simply does not keep all of it permanently. This saves disk space, not automatically the amount of data downloaded initially. A later task needing deleted blocks may require obtaining them again. [2] [7]

Bitcoin Core v29.0 considers, among other things, the age of the latest accepted block, minimum accumulated work and loading status. Once this operational flag becomes false (meaning initial synchronization has finished), it does not return to true (meaning it is still in progress) during the same run. It guides program behavior; it is not proof that no newer block exists anywhere. Even losing the connection later does not turn it into a reliable freshness indicator. [2] [5]

A fast connection helps, but the computer must also calculate and write to disk. CPU, memory, storage and peer availability all affect duration. In the technical getblockchaininfo output, verificationprogress estimates validation progress; it is neither a prediction of the minutes remaining nor simply the fraction of bytes downloaded. After a clean shutdown, a later startup can resume saved progress rather than starting everything from scratch. [5] [7]

AssumeUTXO allows a supported UTXO snapshot: a saved state at a particular block. The software checks its contents against an expected fingerprint and can reach the present sooner from that state while processing history in the background. It subsequently compares the state produced by that historical validation too. This is not an arbitrary database from a stranger or a way to avoid ever validating history. Earlier usability and completed historical validation are separate milestones. [4] [8]