AssumeValid

What Is AssumeValid?

AssumeValid is a default-on setting in Bitcoin Core that tells the node to skip signature verification for all blocks that are ancestors of a specific, hardcoded block hash. When a new Bitcoin node syncs the blockchain from scratch, it must validate hundreds of thousands of blocks containing hundreds of millions of transactions. Signature verification is by far the most CPU-intensive step in that process. AssumeValid removes that bottleneck for historical blocks that thousands of nodes have already validated.

The feature was introduced by Gregory Maxwell in PR #9484 and released in Bitcoin Core 0.14.0 in March 2017. It replaced the older checkpoint system with a mechanism that is both more flexible and less trust-dependent: unlike checkpoints, AssumeValid never forces a node to follow a particular chain.

How It Works

During initial block download (IBD), a node processes every block from the genesis block to the current tip. For each transaction in each block, the node normally executes the script that validates the spending conditions: verifying ECDSA or Schnorr signatures, checking timelocks, and evaluating other opcodes. This script execution accounts for the majority of IBD processing time.

AssumeValid introduces a shortcut. The Bitcoin Core source code contains a hash of a recent, known-valid block (updated with each release). When the node encounters a block that is an ancestor of this hash, it skips script validation entirely. Everything else is still checked.

What Is Still Validated

AssumeValid only skips one category of checks. The node continues to perform all of the following:

• Proof-of-work verification: every block header must meet the current difficulty target
• UTXO consistency: every transaction input must reference an existing, unspent output (no double-spending)
• Inflation rules: the coinbase reward must not exceed the allowed block subsidy plus transaction fees
• Block weight and size constraints: blocks must respect the size limit enforced by SegWit
• Merkle root computation: the transaction tree must match the header commitment
• Transaction format and structure: inputs, outputs, and encoding

Because the full UTXO set is built and verified during sync, AssumeValid cannot hide inflation bugs or double-spend attacks. An adversary who managed to insert a malicious AssumeValid hash could, at most, trick the node into accepting a transaction with an invalid signature: a spend that was not authorized by the private key holder.

Gating Conditions

Three conditions must all be met before script validation is skipped for a block:

1. The block must be an ancestor of the configured AssumeValid block hash
2. The chain must have cumulative work at or above nMinimumChainWork, a hardcoded threshold that prevents an attacker from feeding a node a low-difficulty chain
3. The block must be buried under at least two weeks of proof-of-work, ensuring the optimization never applies to recent blocks

If any condition fails, the node performs full signature verification.

Configuration

Node operators can control AssumeValid through the -assumevalid flag:

# Use the compiled-in default (recommended)
bitcoind

# Disable: verify every signature from genesis
bitcoind -assumevalid=0

# Use a custom block hash
bitcoind -assumevalid=00000000000000000000611fd22f2df7c8fbd0688745c3a6c3bb5109cc2a12cb

Setting -assumevalid=0 forces full validation of every block, which is useful for auditing the chain or verifying that the default hash is honest. This roughly doubles IBD time but provides the highest assurance.

Why It Matters

Running a full Bitcoin node is essential for self-sovereign participation in the network. But if IBD takes days instead of hours, fewer people will bother. AssumeValid directly lowers the barrier to running a node by cutting sync time roughly in half without meaningfully reducing security guarantees.

During the Bitcoin Core 0.14.0 development cycle, benchmarks showed reindex time dropping from approximately 6.15 hours to 2.96 hours when AssumeValid was enabled: a reduction driven entirely by skipping signature verification. Combined with other 0.14.0 optimizations, total IBD time dropped from over 36 hours to under 7 hours on contemporary hardware.

For layer-2 protocols like the Lightning Network and Spark, faster node sync matters because these systems depend on users or service providers running full nodes to verify on-chain state. Any improvement that makes full validation more accessible strengthens the security of the broader Bitcoin ecosystem.

AssumeValid vs. AssumeUTXO

AssumeValid and AssumeUTXO are complementary optimizations that address different bottlenecks in IBD. They are often confused because of their similar names, but they work in fundamentally different ways.

AssumeValid processes every block but skips expensive signature math. AssumeUTXO skips the entire historical chain initially, loading a UTXO snapshot so the node can validate new blocks within minutes, then catches up on history in the background. A node can use both optimizations simultaneously. For a deeper comparison of node sync strategies, see the Bitcoin node implementation comparison.

Use Cases

First-Time Node Operators

The most common use case is simply running a new Bitcoin node. AssumeValid is enabled by default, so every new Bitcoin Core installation benefits automatically. Users on consumer hardware (a Raspberry Pi 4 or a modest laptop) see sync times measured in hours rather than days.

Pruned Node Deployment

Pruned nodes discard old block data after validation to save disk space. AssumeValid accelerates the processing phase that pruned nodes still must complete. A recent optimization (PR #27050) takes this further: pruned nodes can skip downloading witness data for assumed-valid blocks, saving over 100 GB of bandwidth during sync since SegWit witness data accounts for roughly half of recent block sizes.

Infrastructure Recovery

When a node crashes or a server must be rebuilt, AssumeValid shortens the time to get back online. For businesses running Lightning routing nodes or exchange infrastructure, this can mean the difference between hours of downtime and a much longer outage.

Risks and Considerations

Trust in the Default Hash

The default AssumeValid hash is chosen by Bitcoin Core developers and reviewed during the release process. Users trust that this hash points to a genuinely valid block. However, this trust is auditable: anyone can run -assumevalid=0 to verify the entire chain independently. The hash itself is visible in the source code at src/kernel/chainparams.cpp, and the block it references can be inspected on any block explorer.

If a malicious hash were somehow inserted into a release, the worst outcome would be accepting blocks with unauthorized spends (invalid signatures). Supply inflation and double-spend attacks remain impossible because UTXO validation is never skipped.

Does Not Replace Full Validation

AssumeValid is an optimization, not a trust shortcut. The node still downloads and processes every block. It still builds the complete UTXO set. It still verifies proof-of-work, block structure, and transaction accounting. Nodes running with AssumeValid produce the same UTXO set as nodes that verify every signature: the only difference is the time it takes.

Hash Staleness Between Releases

The hardcoded AssumeValid hash is updated with each Bitcoin Core release but becomes increasingly stale between releases. A node syncing with a six-month-old release will fully validate all blocks mined since the hash was set. This is by design: the optimization applies only to deeply buried history, and recent blocks always receive full validation.

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.