4

Bitcoin's assumption was to download the blocks and verify it in order to prevent getting fooled.

But by default, the assumevalid option is enabled in the software, which, as I understand it, makes some data (until 2017?) real without verification.

So, can we consider Bitcoin nodes safe? If so, why?

Of course, you can disable this option, but 99% of people may not even know that this option is enabled.

5

which, as I understand it, makes some data (until 2017?) real without verification.

You understand incorrectly. Firstly, the assumevalid blocks is updated at every major release, so it is at most a couple of months out of date for the most recent release. For Bitcoin Core 0.18.0, the assumevalid block is 0x0000000000000000000f1c54590ee18d15ec70e68c8cd4cfbadb1b4f11697eee which is from February of this year.

Secondly, assumevalid does not just make Bitcoin Core blindly accept blocks without validation. Bitcoin Core will still validate most parts of the block, including Proof of Work, UTXOs, amounts, etc. The only thing that is not validated are scripts because scripts are expensive. assumevalid just means that all scripts in transactions included in blocks that are ancestors of the assumevalid block are assumed to be valid.

Since it only assumes this for the ancestors of the assumevalid block, if there were a large work re-org which removed that block from the blockchain, all scripts would be validated.

So, can we consider Bitcoin nodes safe? If so, why?

Yes, we can. Nodes are still validating other important things like PoW, UTXOs, amounts, etc. The block that is chosen for the assumevalid block is always one that is several thousand blocks deep at the time the PR is created to update the assumevalid block, and tens of thousands of blocks deep by the time the release is made. So it is extremely unlikely to be reorged out due to the extremely large amount of work required to do so. Even if it were reorged, Bitcoin Core wouldn't become insecure, it would just be a bit slower.

Furthermore, in order for that block to be updated in the codebase, multiple people need to agree with the change and sign off on it. Many developers do so and go further to PGP sign a message stating that they agree that this block is part of the main Bitcoin chain.

While this does introduce a little bit of trust, people can independently check that that block is part of the main chain be going to block explorers and looking up the block in their own node. They can check that this block and its ancestors are indeed valid.

| improve this answer | |
  • I think the most important aspect of such partial validation is data availability, so I posted my new answer. – Chris Chen Aug 13 at 17:03
  • After posting my new answer, I think although fraud proofs can't save SPV, theoretically it can still help partially validating, fully downloading nodes reduce trust. – Chris Chen Aug 13 at 17:38
0

With assumevalid enabled, a full node skips signature validation (it's "script validation" rather than "signature validation" actually, but validating digital signature is what most scripts do), implicitly trusting the developers who hard-coded the default block hash. However it's not bad, because the most tricky part, data availability, is still fully validated.

Sounds absurd to let everyone to download the whole years of transaction history? Developers just thought exactly the same as you. So they tried to make lightweight SPV client as safe/trustless as full node - the technique or idea to achieve this goal is called "fraud proofs".

Fraud proof was supposed to work a bit like "public opinion supervision", except that it's not "opinion", but "fact" based. For example, if a transaction is spending a coin once again, Merkle proofs of those two spending transactions are the fraud proof. (then the corresponding block which included such double-spending transaction is also proven to be invalid) The proof itself is succinct, and verifiable without full blockchain.

Unfortunately, developers then given up on the idea of fraud proofs just because the data availability (edit: unavailability actually) can't be proven.

You can't know whether a piece of data is available without actually fully downloading it. Edit: You can't validate a piece of data without having it at your hands, therefore generating fraud proofs won't be possible. You are also unable to verify whether a piece of data is really missing without fully downloading it on your own.

Downloading the whole blockchain seems very wasteful especially when pruning is enabled. However, without downloading & validating the full blockchain ledger, you can never know whether something nasty, like inflation, or theft (confiscating coins without giving any valid signature), is hidden in some missing parts.

Even if assumevalid seems to skip some crucial validation steps, by fully downloading the whole blockchain ledger, you have already gained confidence to rule out the "hidden evil" problem above. Although there's still some trust (as mentioned in the beginning of this answer), but with the most tricky problem ruled out, it won't actually matter - real full validation doesn't cost much either, anyone can do it simply with assumevalid=0.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.