AssumeUTXO

Peter is starting his first Full Node, software that checks Bitcoin’s rules for itself. A block groups transactions into a batch added to the shared history. An ordinary start requires working through a long history first. AssumeUTXO lets him begin with a prepared UTXO set: a collection of transaction outputs that remain unspent, each recording an amount and the conditions for spending it. This snapshot captures the state after a particular block. It is neither an archive of all payments nor proof that Peter’s computer has already checked the entire past. [1] [3]

A snapshot cannot be declared correct because of its filename. When loading it through loadtxoutset, Bitcoin Core v29.0 checks its format, base block (the block the snapshot represents) and supported parameters. It also computes a hash of the UTXO contents, a cryptographic fingerprint, and compares it with the expected value before activation. Altered contents cannot pass merely because someone gave the file a trustworthy-looking name. [2] [3] [6]

After accepting the snapshot, the node builds on its state, verifies later blocks and can reach the current end of the chain. It does not accept those blocks without verification: spending conditions and the permitted creation of new bitcoins are still checked. The benefit is that this path to current activity need not wait for the older history to finish. That does not mean the older history has already been checked locally. [1] [6]

Meanwhile, a second state is built from historical blocks, from the beginning up to the snapshot’s base. This is an independent calculation from history, not another copy of the downloaded inventory. For a while, the software therefore maintains two states with different progress. The technical command getchainstates can show them; an active state reaching the latest blocks does not by itself confirm completion of the background work. [1] [8]

The expected hash and supported base block belong to a particular software version. Until Peter’s node has worked through history itself, it relies on the correctness of that embedded information. Comparing hashes lets the node check whether the contents match, but does not by itself establish whether a valid history produced them. If the expected state were wrong, earlier use of the node would rest on that wrong assumption. This is why later historical verification must not be confused with the file check during loading. [2] [6]

A file can come from another operator, but that does not give the operator authority to choose the accepted state. What matters is a match with the value supported by the software, not the provider’s promise. Nor can you load any snapshot from any block: support depends on both the version and the network. Hash checking also does not guarantee delivery or prevent downloading and processing from consuming time, bandwidth and disk space. [2] [4] [7]

When background work reaches the same base block, the node hashes the UTXO set it has built and compares that hash with the expected snapshot hash. It is not comparing today’s state with an old photograph: both refer to the same point in history. If they disagree, the implementation described here shuts the node down and stops using snapshot-derived state. It neither hides the mismatch nor reports successful verification. [1] [6]

AssumeUTXO mainly changes how soon a node becomes usable. Historical downloading and verification continue, and two state databases are temporarily maintained. This requires processing power and disk activity. A Pruned Node saves space by deleting older block files it has already processed; it does not skip rule checks. A Pruned Node can also use a snapshot, but storage savings have their own constraints. Some supporting indexes must process history from the beginning, so an earlier usable node does not make every connected application immediately ready. [5] [7]

The UTXO set contains information about unspent outputs, not the private keys that authorize spending. A digital signature provides proof of authorization for a payment using a private key, a secret numerical value, without revealing that key. The UTXO set is not a wallet backup and cannot restore a lost Seed Phrase, the recovery words of a wallet that uses this recovery method. Old payments may not appear immediately either: finding them can require blocks from before the snapshot. Backing up keys, finding a wallet’s history and verifying network state are different tasks. [1] [7]

The similar names can be confusing. AssumeUTXO starts from loaded state and reconstructs older history in the background. By contrast, assumevalid can, under specific conditions, skip some historical script checks, checks of spending conditions including signatures. It is a separate optimization that can also affect historical verification; completing AssumeUTXO alone does not tell you that it was disabled. When reading instructions, distinguish where the node starts, what it actually checks and when each check finishes. [5] [6]