<p>[Update: With the Bitcoin client v0.7, -loadblock= will allow the client to import blockchain data, securely, from a local blockchain archive rather than from the network.  The <a href="http://eu1.bitcoincharts.com/blockchain/">blockchain download from BitcoinCharts.com</a> can be used for this.  Copy the blk*.dat from that download to a temporary directory and start Bitcoin-qt -loadblock=temp/blk0001.dat   and watch the blocks load fast.]</p>

<p>Going to try to answer the question myself.</p>

<p>Recent copies of the blockchain data files are made available (and digitally signed) by one of the core developers of the Bitcoin.org team.</p>

<ul>
<li><a href="http://eu1.bitcoincharts.com/blockchain/">http://eu1.bitcoincharts.com/blockchain/</a></li>
</ul>

<p>The URL isn't SSL but there is a digital signature that can be used to verify that the binary downloaded matches.</p>

<p>When using these I am trusting that the developer is honest and has not altered the blockchain.  If this developer were to try, invalid data could be injected into the blockchain data file which would then trick my client into verifying transactions that would elsewhere be reject as being invalid.</p>

<p>There is even a slightly older archive of the Blockchain from the Bitcoin Sourceforge distribution site as well:</p>

<ul>
<li><a href="http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/">http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/</a></li>
</ul>

<p>I now see others providing binary blockchain data as well.</p>

<ul>
<li><a href="http://bitcointalk.org/index.php?topic=78925.0">http://bitcointalk.org/index.php?topic=78925.0</a></li>
<li><a href="http://pro2host.com/cryptocoin/blockchains">http://pro2host.com/cryptocoin/blockchains</a></li>
</ul>

<p>This site doesnt' use SSL nor is it there a digital signature to ensure the download is the same as the one the author hosts.</p>

<p>While these methods aren't generally considered secure, there may be situations where security can be traded off for the convenience.  For instance, if you only will be spending previously received coins and not receiving, there is little risk in using one of these blockchain files.</p>

CC BY-SA 3.0
2012-05-02T21:40:41.787Z
2012-09-24T20:10:13.813Z
2012-09-24T20:10:13.813Z
Stephen Gornick
<p>Short answer: If the client checks the blocks it's fine. Clients won't usually do this this and the lack of certainty about database is risky. What attack is possible will depend on client specifics but attacks most likely exist.</p>

<p>You would either have to trust that person and have a data integrity measure or revalidate the downloaded chain yourself. Do remember that the default client treats already downloaded blocks fairly differently from downloaded blocks. </p>

<p>A "low-tech" solution could be to run the bitcoin client twice, one with and one without the downloaded chain. Set them up to connect to eachother. Now one of the two will download &amp; verify the chain locally. Not the most efficient way but it is as trustable as downloading from the web.</p>

<p>Edit: after a discussion with Pieter Wuille I'm sure I'm not sure about how safe downloaded chains are and removed claims towards safety.</p>

CC BY-SA 3.0
2012-05-05T01:35:34.957Z
I don't agree entirely: if a popular blockchain download site would hand out a corrupted blockchain, and a significant portion of the network would use these, there is a risk for a split the second on the of the corrupted transactions are split.
Pieter Wuille
CC BY-SA 3.0
2012-05-06T11:55:40.197Z
I don't quite see what you mean. Do realise that the miners are organised in pools and that these pools will have legitimate chains. These pools' contribution determine the longest chain, not the end-users. After a few confirmations a transaction can be fairly trustworthy, as with all other transactions.
Lodewijk
CC BY-SA 3.0
2012-05-06T12:27:24.590Z
But if 10% of users use the same corrupted download in their nodes, one transaction could seem invalid to them, after which they ignore the real longest chain. If they have some mining power as well (p2pool users, for example), they will create a block chain fork (albeit very slowly, initially.
Pieter Wuille
CC BY-SA 3.0
2012-05-06T13:48:25.937Z
I see. The client will have to evaluate the scripts but that is default behaviour. So popular a bad chain could easily be spotted, but that's a weak argument. It is fairly stealthy as many transactions could still process normally. This is a fair danger. Checking whether the most-recent mercle hash is the same as one published somewhere should counteract this attack. Checkpoints also kill these bad chains, as they no longer line up. Introduce daily checkpoints?
Lodewijk
CC BY-SA 3.0
2012-05-06T13:56:56.847Z
I see. Shouldn't connecting with random other nodes get you the legitimate blocks as if you're on just-any fork? The blockchain forks a little all the time, that gets resolved very decently. The part after the latest checkpoint must be considered a potential fork, downloaded or not.
Lodewijk
CC BY-SA 3.0
2012-05-06T13:58:33.820Z
Merkle hashes are inside transactions, we are talking about blocks. And all checkpoints do is guarantee that when a particular block is downloaded, its hash is correct, locking that and every part before it in the chain. However, if you download the entire block database in final form, all these checks have already been performed. They are not performed again at startup after download... 0.7.0 will introduce a way to load blocks from a file (while checking them entirely). Without that, downloading a block database should be considered risky.
Pieter Wuille
CC BY-SA 3.0
2012-05-06T13:59:57.860Z
Interaction with other nodes doesn't help a thing. If your blockchain database is corrupted, you already have the blocks. They will not be downloaded again, as your client doesn't realize that the ones you already have are invalid.
Pieter Wuille
CC BY-SA 3.0
2012-05-06T14:03:03.627Z
let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/3344/discussion-between-lodewijk-and-pieter-wuille)
Lodewijk
CC BY-SA 3.0
2012-05-04T19:57:44.257Z
2012-05-06T15:13:59.047Z
2012-05-06T15:13:59.047Z
Lodewijk
<p>There is a recent archive with raw blockchain data and instructions how to get your bitcoin-qt client running fast at:</p>

<ul>
<li><a href="https://github.com/dailyblockchain/bc" rel="nofollow">https://github.com/dailyblockchain/bc</a></li>
</ul>

<p>I've followed the instructions and it worked perfectly. I had my client up and running in under 3h </p>

CC BY-SA 3.0
2013-12-06T01:04:16.390Z
2013-12-06T01:04:16.390Z
1000freecoins
<p>So far as I know, there's no conceivable attack model if you're going to use the block chain to seed the regular Bitcoin client. It won't accept an invalid block. And it understands that the "longest" block chain wins. So a compromised file that was longer than the official block chain cannot exist, and a compromised file that was shorter would just be rejected as soon as the client connected to the network.</p>

<p>On startup, the client checks to make sure the chain is basically valid and contains the most recent checkpoint.</p>

<p>If there is any attack that works in this way, it's a defect in the client. Because someone could send you the same "broken" blockchain over the network too.</p>

CC BY-SA 3.0
2012-05-04T13:42:52.080Z
Many more checks are done on blocks received from the network than blocks read from disk; startup would be unbearably slow if a complete check of the blockchain was done every time you start.
gavinandresen
CC BY-SA 3.0
2012-05-04T20:14:13.183Z
I was under the impression a full check was done on every block after the last checkpoint. If that's not true, ...
David Schwartz
CC BY-SA 3.0
2012-05-05T01:33:14.803Z
The checks performed can be divided in three groups: A) block validity, B) linking and C) script validity. A includes rules like proof-of-work, amount generated, ... B is about whether transactions are not double spends. C is whether spends are done using the correct key. When downloading blocks, A and B are performed, and C after the last checkpoint. At startup, only A is performed on the last 2500 blocks. Since 0.6.0, you can use -checklevel=N (with N>1) to verify some of B's rules as well at startup.
Pieter Wuille
CC BY-SA 3.0
2012-05-02T22:01:22.860Z
2012-05-02T22:01:22.860Z
David Schwartz
<p>I see several sources for binary downloads of the Bitcoin blockchain.  Can any of these be used securely?</p>

CC BY-SA 3.0
2012-05-02T21:53:07.957Z
Does Checkblocks help at all? 

 - http://bitcointalk.org/index.php?topic=74858.0
Stephen Gornick
CC BY-SA 3.0
2012-05-02T23:03:43.737Z
No. Even at the highest -checklevel, signatures are not verified.
Pieter Wuille
CC BY-SA 3.0
2012-05-03T08:59:51.630Z
URL for the blockchain data files from Sourceforge: http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/
Stephen Gornick
CC BY-SA 3.0
2012-05-03T16:32:25.463Z
I believe the best answer to this question is "by letting bitcoind download it from the network" (note that you can use -addnode or -connect= to connect directly to a known reliable node). Also, I have a patch ready for 0.7.0 which will allow importing a blk0000?.dat file directly, with the same verification as done for blocks downloaded from the network. It is hardly slower than downloading though, as the index needs to be rebuilt.
Pieter Wuille
<blockchain><security><trust>
How can one download the initial Blockchain data files securely?
Stephen Gornick
# How can one download the initial Blockchain data files securely?

(Asked by: username_0 on 2012-05-02)

I see several sources for binary downloads of the Bitcoin blockchain. Can any of these be used securely?

**Tags:** blockchain, security, trust

> **Comments:**
> **username_0**: Does Checkblocks help at all?    - http://bitcointalk.org/index.php?topic=74858.0  
> **username_1**: No. Even at the highest -checklevel, signatures are not verified.  
> **username_0**: URL for the blockchain data files from Sourceforge: http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/  
> **username_1**: I believe the best answer to this question is "by letting bitcoind download it from the network" (note that you can use -addnode or -connect= to connect directly to a known reliable node). Also, I have a patch ready for 0.7.0 which will allow importing a blk0000?.dat file directly, with the same verification as done for blocks downloaded from the network. It is hardly slower than downloading though, as the index needs to be rebuilt.  

---

## 4 answers

### Answer by username_4 on 2012-05-02. Score: 7 | Accepted answer

So far as I know, there's no conceivable attack model if you're going to use the block chain to seed the regular Bitcoin client. It won't accept an invalid block. And it understands that the "longest" block chain wins. So a compromised file that was longer than the official block chain cannot exist, and a compromised file that was shorter would just be rejected as soon as the client connected to the network.

On startup, the client checks to make sure the chain is basically valid and contains the most recent checkpoint.

If there is any attack that works in this way, it's a defect in the client. Because someone could send you the same "broken" blockchain over the network too.

> **Comments:**
> **username_5**: Many more checks are done on blocks received from the network than blocks read from disk; startup would be unbearably slow if a complete check of the blockchain was done every time you start.  
> **username_4**: I was under the impression a full check was done on every block after the last checkpoint. If that's not true, ...  
> **username_1**: The checks performed can be divided in three groups: A) block validity, B) linking and C) script validity. A includes rules like proof-of-work, amount generated, ... B is about whether transactions are not double spends. C is whether spends are done using the correct key. When downloading blocks, A and B are performed, and C after the last checkpoint. At startup, only A is performed on the last 2500 blocks. Since 0.6.0, you can use -checklevel=N (with N>1) to verify some of B's rules as well at startup.  

---

### Answer by username_0 on 2012-05-02. Score: 5

[Update: With the Bitcoin client v0.7, -loadblock= will allow the client to import blockchain data, securely, from a local blockchain archive rather than from the network. The [blockchain download from BitcoinCharts.com](http://eu1.bitcoincharts.com/blockchain/) can be used for this. Copy the blk\*.dat from that download to a temporary directory and start Bitcoin-qt -loadblock=temp/blk0001.dat and watch the blocks load fast.]

Going to try to answer the question myself.

Recent copies of the blockchain data files are made available (and digitally signed) by one of the core developers of the Bitcoin.org team.

* <http://eu1.bitcoincharts.com/blockchain/>

The URL isn't SSL but there is a digital signature that can be used to verify that the binary downloaded matches.

When using these I am trusting that the developer is honest and has not altered the blockchain. If this developer were to try, invalid data could be injected into the blockchain data file which would then trick my client into verifying transactions that would elsewhere be reject as being invalid.

There is even a slightly older archive of the Blockchain from the Bitcoin Sourceforge distribution site as well:

* <http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/>

I now see others providing binary blockchain data as well.

* <http://bitcointalk.org/index.php?topic=78925.0>
* <http://pro2host.com/cryptocoin/blockchains>

This site doesnt' use SSL nor is it there a digital signature to ensure the download is the same as the one the author hosts.

While these methods aren't generally considered secure, there may be situations where security can be traded off for the convenience. For instance, if you only will be spending previously received coins and not receiving, there is little risk in using one of these blockchain files.


---

### Answer by username_2 on 2012-05-04. Score: 1

Short answer: If the client checks the blocks it's fine. Clients won't usually do this this and the lack of certainty about database is risky. What attack is possible will depend on client specifics but attacks most likely exist.

You would either have to trust that person and have a data integrity measure or revalidate the downloaded chain yourself. Do remember that the default client treats already downloaded blocks fairly differently from downloaded blocks.

A "low-tech" solution could be to run the bitcoin client twice, one with and one without the downloaded chain. Set them up to connect to eachother. Now one of the two will download & verify the chain locally. Not the most efficient way but it is as trustable as downloading from the web.

Edit: after a discussion with username_1 username_1 I'm sure I'm not sure about how safe downloaded chains are and removed claims towards safety.

> **Comments:**
> **username_1**: I don't agree entirely: if a popular blockchain download site would hand out a corrupted blockchain, and a significant portion of the network would use these, there is a risk for a split the second on the of the corrupted transactions are split.  
> **username_2**: I don't quite see what you mean. Do realise that the miners are organised in pools and that these pools will have legitimate chains. These pools' contribution determine the longest chain, not the end-users. After a few confirmations a transaction can be fairly trustworthy, as with all other transactions.  
> **username_1**: But if 10% of users use the same corrupted download in their nodes, one transaction could seem invalid to them, after which they ignore the real longest chain. If they have some mining power as well (p2pool users, for example), they will create a block chain fork (albeit very slowly, initially.  
> **username_2**: I see. The client will have to evaluate the scripts but that is default behaviour. So popular a bad chain could easily be spotted, but that's a weak argument. It is fairly stealthy as many transactions could still process normally. This is a fair danger. Checking whether the most-recent mercle hash is the same as one published somewhere should counteract this attack. Checkpoints also kill these bad chains, as they no longer line up. Introduce daily checkpoints?  
> **username_2**: I see. Shouldn't connecting with random other nodes get you the legitimate blocks as if you're on just-any fork? The blockchain forks a little all the time, that gets resolved very decently. The part after the latest checkpoint must be considered a potential fork, downloaded or not.  
> **username_1**: Merkle hashes are inside transactions, we are talking about blocks. And all checkpoints do is guarantee that when a particular block is downloaded, its hash is correct, locking that and every part before it in the chain. However, if you download the entire block database in final form, all these checks have already been performed. They are not performed again at startup after download... 0.7.0 will introduce a way to load blocks from a file (while checking them entirely). Without that, downloading a block database should be considered risky.  
> **username_1**: Interaction with other nodes doesn't help a thing. If your blockchain database is corrupted, you already have the blocks. They will not be downloaded again, as your client doesn't realize that the ones you already have are invalid.  
> **username_2**: let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/3344/discussion-between-username_2-and-username_1-username_1)  

---

### Answer by username_3 on 2013-12-06. Score: 0

There is a recent archive with raw blockchain data and instructions how to get your bitcoin-qt client running fast at:

* <https://github.com/dailyblockchain/bc>

I've followed the instructions and it worked perfectly. I had my client up and running in under 3h


---

