pull down to refresh
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 assumevalid feature 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 assumevalid makes 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 assumevalid hash, 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.
Correction: that question was asked by fervi, I just edited it.