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

  • Does Checkblocks help at all? - bitcointalk.org/index.php?topic=74858.0 – Stephen Gornick May 2 '12 at 21:53
  • No. Even at the highest -checklevel, signatures are not verified. – Pieter Wuille May 2 '12 at 23:03
  • URL for the blockchain data files from Sourceforge: sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain – Stephen Gornick May 3 '12 at 8:59
  • 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 May 3 '12 at 16:32
up vote 7 down vote accepted

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.

  • 2
    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 May 4 '12 at 13:42
  • I was under the impression a full check was done on every block after the last checkpoint. If that's not true, ... – David Schwartz May 4 '12 at 20:14
  • 3
    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 May 5 '12 at 1:33

[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 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.

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:

I now see others providing binary blockchain data as well.

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.

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 Pieter Wuille I'm sure I'm not sure about how safe downloaded chains are and removed claims towards safety.

  • 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 May 5 '12 at 1:35
  • 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 May 6 '12 at 11:55
  • 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 May 6 '12 at 12:27
  • 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 May 6 '12 at 13:48
  • 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 May 6 '12 at 13:56

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

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

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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