pull down to refresh

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.

Sorry for using the term "checkpoint" for the assumeValid hash, which clashes with the --checkpoints flag that is no longer used. The hashes used in --assumeValid seem like checkpoints to me, just came out naturally but I am trying to think of a better term. "Trusted States" maybe?

also #1445840

reply
645 sats \ 0 replies \ @Murch 2 Mar

I don't think trusted state captures the nuance well.
It's a much weaker trust assumption than that confers.

You're verifying that you've received exactly the same Blockchain data that the network had buried by at least a month of pow at the release of the software, and if that's the case, you assume that you'll find the scripts to have been valid. You still check most of the block rules, tx rules, just not the result of evaluating the scripts.
You did check that the scripts are byte-by-byte exactly the same though.

reply

deleted by author