4

I know Bitcoin Core downloads and processes the full chain much quicker now than it used to but what exactly is so bad about downloading a compressed blocks, chainstate and database folder from a third party?

In the event of any malicious changes to the chainstate, wouldn't Bitcoin Core at its startup reject the new blocks anyway?

Improve this question

2 Answers 2

Reset to default
10

No, the chainstate is the nodes view of correctness. It would take many hours or days to re-verify the whole chain on most hardware, so an assumption is made that the state stored at the previous shutdown is most likely correct. There's some sanity checking of the previous couple of blocks to make sure there is no gross accidental corruption, but malicious modifications of the chainstate before that time will not be caught.

A maliciously modified chainstate can contain fake outputs that do not exist in the canonical one, meaning you could be duped into accepting a false transaction paying money to you that nobody else would consider valid. If any significant portion of the network was downloading unverified chainstate databases it would be a considerable issue.

Improve this answer
3

The challenge is essentially who you are downloading from. If you already have a full node that has completed the IBD (initial block download) verification process you may choose to just transfer that over that blockchain to a second full node you are setting up to save on completing the process a second time.

However, if you download it from a malicious party they could send you an entirely independent blockchain with orders of magnitude less proof of work. If they also controlled some of the peers you are connected to they could continue to feed you new blocks built on top of this independent blockchain. Unless you did sanity checks against a third party block explorer or verified the accumulated proof of work you may struggle to work out what has happened.

The Bitcoin protocol is designed to be trust minimized. If you relax those assumptions and start trusting third parties you do start to open up "security holes" in Nick Szabo's parlance.

Improve this answer
5
  • 5
    If it's actually a less-work chain, it'll quickly be overtaken as soon as you connect to real nodes. The concern is that a malicious chainstate can just give an arbitrary state of the system - including giving themselves more money - with the same chain.
    – Pieter Wuille
    Dec 8, 2020 at 17:06
  • 2
    If you had a million blocks on the malicious party's "fake" blockchain (with orders of magnitude less accumulated proof of work) and then you learnt about a block built on top of the "true" blockchain the software would detect this, ditch the entire "fake" blockchain and start verifying from genesis on the "true" blockchain?
    – Michael Folkson
    Dec 8, 2020 at 19:51
  • 3
    Yes, by definition. That's proof of work, you have to accept the most-work chain among all valid chains you know of.
    – Pieter Wuille
    Dec 8, 2020 at 20:51
  • There are effective checkpoints in Core? And these aren't hardcoded? Is there a number of blocks (e.g. a million) where after that point you wouldn't verify from genesis no matter how significant the proof of work on a block you received from a honest peer?
    – Michael Folkson
    Dec 9, 2020 at 13:54
  • Yeah, this only works back to the last checkpoint you've passed. Beyond that, no, it should download and verify headers from any peer who claims to have a better chain. Note however that the difficulty level at the time of the last checkpoint is nontrivial, so constructing a headers chain that branches off at that point will have a substantial cost per block.
    – Pieter Wuille
    Dec 9, 2020 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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