<p>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.</p>
<p>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.</p>
<p>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 &quot;security holes&quot; in Nick Szabo's <a href="https://nakamotoinstitute.org/trusted-third-parties/" rel="nofollow noreferrer">parlance</a>.</p>

CC BY-SA 4.0
2020-12-08T17:06:53.217Z
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
CC BY-SA 4.0
2020-12-08T19:51:12.863Z
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
CC BY-SA 4.0
2020-12-08T20:51:36.120Z
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
CC BY-SA 4.0
2020-12-09T13:54:23.160Z
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
CC BY-SA 4.0
2020-12-09T18:17:52.457Z
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
CC BY-SA 4.0
2020-12-08T11:51:58.887Z
2020-12-08T11:51:58.887Z
Michael Folkson
<p>No, the <code>chainstate</code> 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 <em>accidental corruption</em>, but <em>malicious modifications</em> of the <code>chainstate</code> before that time will not be caught.</p>
<p>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.</p>

CC BY-SA 4.0
2020-12-08T06:59:47.490Z
2020-12-09T04:49:13.690Z
2020-12-09T04:49:13.690Z
Claris
<p>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 <code>blocks, chainstate and database</code> folder from a third party?</p>
<p>In the event of any malicious changes to the chainstate, wouldn't Bitcoin Core at its startup reject the new blocks anyway?</p>

<bitcoin-core><synchronization>
Why is it bad to download the full chain from a third party with Bitcoin Core?
Toodarday
# Why is it bad to download the full chain from a third party with Bitcoin Core?

(Asked by: username_0 on 2020-12-08)

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?

**Tags:** bitcoin-core, synchronization


---

## 2 answers

### Answer by username_3 on 2020-12-08. Score: 10 | Accepted answer

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.


---

### Answer by username_1 on 2020-12-08. Score: 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](https://nakamotoinstitute.org/trusted-third-parties/).

> **Comments:**
> **username_2**: 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.  
> **username_1**: 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?  
> **username_2**: Yes, by definition. That's proof of work, you have to accept the most-work chain among all valid chains you know of.  
> **username_1**: 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?  
> **username_2**: 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.  

---

