You are six hours into syncing a fresh Bitcoin node. The progress bar, if you could call it that, suggests you are somewhere in 2017. Your laptop fan has been running at full pitch since mid-morning. The chain is long, every block since January 2009 needs to be downloaded, parsed, and verified, and without any shortcuts a modest home machine might spend two or three days just catching up to the present.
Bitcoin Core ships with a shortcut. It's called `assumevalid`, and understanding it properly requires separating two things most people conflate: downloading and replaying the chain versus verifying every cryptographic script in every transaction on that chain. `assumevalid` skips the second task for history older than a certain block. It does not skip the first.
That distinction is the whole story.
What the Parameter Actually Does
Every Bitcoin transaction contains a locking script (what you have to prove to spend coins) and an unlocking script (the proof itself). A full node normally executes both, for every input, in every transaction, in every block. That's billions of script evaluations across the full chain history.
`assumevalid` is a hardcoded block hash included in each Bitcoin Core release. When your node syncs and reaches that block, it stops executing scripts for any transaction buried deeper in the chain than that hash. It still downloads every block. It still validates proof-of-work. It still checks that transaction amounts add up, that no coins are created from nothing, that block headers chain correctly. The only thing it skips is the script interpreter running on old inputs.
Consider a concrete scenario. Suppose the hardcoded hash corresponds to block 750,000. Your node downloads blocks 1 through 749,999, confirms the proof-of-work on each, checks that no block mints more than the allowed subsidy, verifies that the UTXO set arithmetic is consistent, and builds the full transaction graph. It just doesn't run `OP_CHECKSIG` on a 2014 transaction spending a Pay-to-PubKey output. From block 750,001 onward, full script verification resumes for every input, no exceptions.
The practical result: initial block download on consumer hardware that might take 48 hours drops to something closer to 6 to 10 hours, depending on disk speed and CPU.
Why This Isn't Trusting a Peer
This is the part that trips people up, and it rewards precise reading.
The hash baked into your Bitcoin Core binary was chosen by the developers who compiled that release, reviewed the chain, and agreed on a block that had accumulated an enormous amount of proof-of-work. You are not asking any peer on the network to tell you which block to trust. You are trusting the software you chose to install, the same way you trust that the SHA-256 implementation in that software is correct. Those are not categorically different acts of faith.
If a malicious majority of miners had somehow rewritten history below that block, they would also have had to regenerate all the proof-of-work now sitting on top of it. That's the actual economic guarantee. The hash isn't a shortcut around proof-of-work. It's a pointer into a chain that already has proof-of-work protecting it.
You can also opt out entirely. Running Bitcoin Core with `-assumevalid=0` disables the parameter and forces full script verification from genesis. Your sync will be slower. Your security model will be, in a narrow technical sense, more complete. Whether that tradeoff is worth it for a home node operator is a judgment call, not a clear-cut win.
The Ledger It Does and Doesn't Build
One thing `assumevalid` emphatically does not skip is constructing the UTXO set. The Unspent Transaction Output set is Bitcoin's live ledger: every coin that exists right now, and who can spend it. Your node builds this from scratch, block by block, even for the history where scripts aren't checked.
Think of it this way. The UTXO set is the car on the road. Script verification is auditing the factory receipts for every component that went into building it over the last decade. `assumevalid` says: the car is running, the proof-of-work is enormous, the amounts all balance. Audit the factory receipts from a recent date forward, and treat the accumulated work behind you as its own guarantee.
This is also why `assumevalid` is meaningfully different from checkpoints, which Bitcoin Core used in older versions. Checkpoints hardcoded specific block hashes and rejected any chain that didn't include them, which was a genuine consensus rule enforced by the node. `assumevalid` has no effect on which chain your node follows. It only affects what computation your node performs on the chain it does follow. A node running `assumevalid` will still switch to a longer valid chain, even if that chain's history below the hash was never script-verified locally.
How the Hash Gets Chosen, and What Could Go Wrong
The Bitcoin Core developers update the `assumevalid` hash with each major release, typically advancing it to a block that is several months old at release time, ensuring it has accumulated substantial proof-of-work and economic finality. The process is transparent: the hash is visible in the source code, any developer can audit the choice, and anyone who disagrees can compile Core with a different value or use a different client.
The honest failure mode runs like this. If the developers themselves were compromised and inserted a malicious hash pointing to a block that somehow concealed an invalid transaction, a node using `assumevalid` would not catch it through script verification. It would catch it through UTXO accounting (amounts must balance) but not through a bad signature on an old input.
This is a real trust surface. Smaller than critics imagine, but real.
Exploiting it would require compromising the Core release process and simultaneously constructing a chain with more cumulative proof-of-work than the honest chain. Both conditions at once. The risk is not zero, but characterizing it as a gaping hole misreads the actual attack geometry.
Two node operators, call them Priya and Marcus, both spin up fresh nodes from the same Bitcoin Core release. Priya runs the defaults. Marcus runs `-assumevalid=0`. Marcus's node finishes syncing roughly 30 hours after Priya's. Both end up with identical UTXO sets. Both verify every script from the `assumevalid` block height forward. The practical difference in their day-to-day security posture is negligible. The philosophical difference is real, and anyone who tells you otherwise is collapsing a meaningful distinction for rhetorical convenience.
Is your node's current `assumevalid` hash something you've actually looked up? It lives in `src/kernel/chainparams.cpp` in the Core repository. Thirty seconds of curiosity, if you're running a node and haven't checked.
Bitcoin's security model has always been probabilistic and layered, not binary. `assumevalid` is an honest engineering tradeoff, documented in the open, rejectable by any user, and substantially protected by the same proof-of-work that secures everything else. The choice was never between fully trustless and compromised. Proof-of-work is expensive, that expense is the guarantee, and the hash simply tells your node where to start counting the receipts.