This is is enabled by default in bitcoin core.
Little back and forth between murch and ava chow:
https://bitcoin.stackexchange.com/questions/88652/does-assumevalid-lower-the-security-of-bitcoin
YES33.3%
NO66.7%
6 votes \ 16h left
pull down to refresh
Correction: that question was asked by fervi, I just edited it.
Thanks murch, sorry for the confusion Ava.
It seems like there's a bit of a sour dough bread and starter yeast metaphor.
You need some bitcoin node running, that you trust, that you synced from genesis or that someone you trust synced from genesis. That's your starter yeast.
If you have that and want a new node (new loaf of bread), you take a hash of recent block or utxo set commmitment from trusted validated node and sync from there no problem and no need to redo all the work. To make it a bit safer have the block be recent but not too recent, ie sufficiently buried that the amount of work for an attacker to recreate the hashes seems sufficiciently unlikely.
the real issues with assumevalid are
-- A do you trust bitcoin core?
-- B is the checkpoint buried under enpugh work that it feels like you don't even need to trust bitcoin core?
-- if neither A not B by itself is enough to achieve trust, is A + B together enough, and if so why?
Would you agree, or would you say it is more nuanced than that.
The
assumevalidfeature still checks that all transactions’ content matches the corresponding txid and that all txids are committed to by the block. This already guarantees that you get exactly the same blockchain byte-by-byte as everyone else on the network. It also runs most of the other checks transactions and blocks. E.g., that transactions are well-formed, there is no double-spending, the proof-of-work rules, block weight limit, etc.The assumption that
assumevalidmakes is that the scripts in the transactions are valid, i.e., that the signatures, input scripts, and output scripts would evaluate satisfactorily. This assumption is reasonable, because the transactions are buried by months of proof of work (or however much time you set a manual assumevalid point into the past), and the entire network has been building on these transactions for months. If any of the scripts had been invalid, nodes should have rejected the transactions months ago. It would be entirely unexpected for anyone to spend all this proof-of-work to extend an invalid chain. However, this does represent a (small!) security reduction traded-off for a big speed-up.Even if you configure a custom
assumevalidhash, your node will always follow the most-proof-of-work chain it learns about. If the configured hash is not in the chain your node is processing, it will do full script validation for the entire blockchain instead.Either way, you always trust the software you’re running to work as advertised. If the software is malicious or has defects, you could have any sort of unacceptable behavior, so that’s not a new assumption.
Checkpoints are a related but different concept which Bitcoin Core no longer uses.
I don't think assumevalid should be enabled by default. AssumeUTXO is a more performant tradeoff if you are willing to sacrifice trust.
fwiw I think both --assumevalid and --assumeutxo reduce bitcoin security.
what I am unclear on is HOW MUCH each one reduces security. just a tiny bit, or enough to matter?
The --assumevalid flag is often misunderstood. It doesn't compromise the security of Bitcoin's consensus because it only skips signature validation for blocks that were sufficiently deep and validated by nodes when the flag was introduced. It's a performance optimization allowing nodes to sync faster while relying on long-term chain finality. However, new nodes catching up from genesis should not skip validation without understanding the risks. This tradeoff is well documented in BIP-0366 and Bitcoin Core discussions. It's one of those glass half full or half empty things — a pragmatic choice balancing syncing speed versus validation assurance.
The --assumevalid flag is an interesting trade-off in Bitcoin Core, designed to speed up initial block download by assuming certain validation on old blocks. It's enabled by default with a checkpoint block to prevent reorg attacks on the chain's distant past. Security isn't really compromised for modern blocks, but it's a reminder that checkpoints introduce a slight trust assumption. This is why full node operators concerned with maximal security might choose to disable it or independently verify history. It's one of those pragmatic choices balancing security and usability.