Assumed IBD

What Is Assumed IBD?

Assumed IBD (Assumed Initial Block Download) describes the node synchronization process enabled by Bitcoin Core's AssumeUTXO feature. In traditional initial block download (IBD), a new node must download, validate, and replay every block from the genesis block to the current chain tip before it can participate in the network. Depending on hardware, this process can take many hours or even days.

Assumed IBD changes this by allowing a node to load a serialized snapshot of the UTXO set at a specific block height. Once loaded, the node can immediately begin validating new blocks from that height forward. The traditional full validation from genesis still happens, but it runs in the background rather than blocking the node from being useful.

The concept was proposed by James O'Beirne on the bitcoin-dev mailing list in April 2019. After years of development and review, AssumeUTXO reached mainnet readiness in Bitcoin Core 28.0, released in October 2024, with a hardcoded snapshot at block height 840,000.

How It Works

Assumed IBD introduces a two-phase synchronization process. Instead of a single linear validation from genesis to tip, the node runs two parallel chainstate validations managed by Bitcoin Core's ChainstateManager.

Phase 1: Snapshot Loading

1. An operator obtains a UTXO snapshot file, either by generating one from a fully synced node using the dumptxoutset RPC or by downloading one from a trusted source
2. The operator loads the snapshot into the new node using the loadtxoutset RPC command
3. Bitcoin Core checks the snapshot's hash against a value hardcoded in the node's source code: if the hashes do not match, the node rejects the snapshot
4. The node creates a "snapshot chainstate" using the loaded UTXO set and begins downloading and validating new blocks from the snapshot height to the current tip

At this point, the node is functionally operational. It can validate new transactions, serve blocks to peers, and participate in the network, all within minutes rather than hours.

Phase 2: Background Validation

1. Simultaneously, the node creates a second "background chainstate" that begins a traditional IBD from the genesis block
2. This background process downloads and fully validates every historical block, building the UTXO set from scratch
3. When background validation reaches the snapshot height, the node independently computes the UTXO set hash and compares it to the hardcoded value
4. If the independently computed hash matches the hardcoded hash, the snapshot is confirmed valid and the background chainstate is merged
5. If the hashes do not match, the node shuts down with an error, because the snapshot was invalid

Snapshot Generation

There is no official distribution channel for UTXO snapshots. Bitcoin Core provides two RPC commands for working with snapshots:

# On a fully synced node, generate a snapshot
bitcoin-cli dumptxoutset /path/to/snapshot.dat

# On a new node, load the snapshot
bitcoin-cli loadtxoutset /path/to/snapshot.dat

# Monitor the sync progress of both chainstates
bitcoin-cli getchainstates

The dumptxoutset command serializes the current UTXO set into a file. The loadtxoutset command loads that file, but only accepts snapshots whose hash matches a value compiled into the binary. Users cannot load arbitrary snapshots without modifying and recompiling the source code.

Assumed IBD vs. AssumeValid

Both Assumed IBD and assumevalid use hardcoded hashes to speed up synchronization, but they optimize different parts of the process:

AssumeValid is enabled by default and reduces sync time modestly by skipping expensive cryptographic checks. Assumed IBD is opt-in and dramatically reduces time to usability by deferring the entire historical validation process. Both features can work together: the background validation in Assumed IBD also uses assumevalid to skip signature checks for old blocks.

For a deeper comparison, see AssumeValid in Bitcoin Core and AssumeUTXO: How New Bitcoin Nodes Sync in Minutes.

Trust Model and Security

Assumed IBD introduces a temporary trust assumption that is eventually eliminated through background validation. During the window between snapshot loading and background validation completion, the node trusts that the hardcoded UTXO set hash is correct. This hash is reviewed by multiple Bitcoin Core developers before each release and is part of the peer-reviewed source code.

What the Hash Guarantees

The hardcoded hash in Bitcoin Core is a commitment to the exact state of the UTXO set at a specific block height. If anyone modified even a single output in the snapshot (adding coins that do not exist, removing coins that do, or changing amounts), the hash would not match and the node would reject the snapshot.

What the Hash Does Not Guarantee

Before background validation completes, the node has not independently verified the full proof-of-work chain that produced the UTXO set. A compromised hash in the source code could theoretically lead a node to accept an invalid chain state. This is why the hash undergoes the same peer review process as any other consensus code change, and why background validation exists as the ultimate verification step.

Use Cases

• Rapid node deployment: operators who need to bring new full nodes online quickly can have a validating node running in minutes instead of waiting for a traditional IBD that may take over ten hours
• Disaster recovery: if a node's chainstate becomes corrupted, the operator can load a snapshot and resume operations while background validation rebuilds the full state
• Lowering the barrier to running a node: the long sync time of traditional IBD discourages users from running their own nodes, and Assumed IBD reduces this friction significantly
• Testing and development: developers can spin up fully functional Bitcoin nodes quickly for testing without waiting for a complete sync

You can compare sync times across different node configurations using the Bitcoin Node Sync Time Comparison tool.

Risks and Considerations

Temporary Trust Window

Between snapshot load and background validation completion, the node operates on an assumption rather than independent verification. During this window, the node trusts that the Bitcoin Core developers correctly computed and reviewed the hardcoded hash. This trust is eventually eliminated once background validation finishes, but until then the security model differs from a node that has validated every block from genesis.

No Official Snapshot Distribution

Bitcoin Core does not distribute snapshot files. Users must generate snapshots themselves from a synced node or obtain them from a third party. While the hardcoded hash prevents loading a tampered snapshot, the user still needs to acquire the file from somewhere. A snapshot whose hash does not match the hardcoded value is simply rejected.

Disk and Resource Usage

During background validation, the node maintains two separate chainstate databases simultaneously. This increases disk usage and I/O load until the background validation completes and the chainstates are merged. On resource-constrained hardware, this parallel workload can slow down both the foreground sync and the background validation.

Snapshot Compatibility

The snapshot format was redesigned in Bitcoin Core 28.0, making snapshots from earlier development versions incompatible. Each Bitcoin Core release includes hardcoded hashes for specific block heights, and only snapshots matching those hashes can be loaded. Users must ensure they are using a snapshot compatible with their version of Bitcoin Core.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.