I regularly update this old post with full dumps of the CLAM blockchain in bootstrap.dat format to make it easier for people to get their CLAM client synced up:


Last night in the Just-Dice chat, Thirdspace asked about the possibility of generating and syncing from "partial" bootstrap.dat files. Suppose your client went out of sync a few weeks ago and is 20,000 blocks behind. You don't want to download and import the whole bootstrap.dat file because you already have 95% of it. Is there some way of having someone make a bootstrap.dat file with just the blocks you need?

Well, the bootstrap file format is very simple: it's pretty much just the raw block data. There's no reason it has to start at block 0. So I made a commit to the CLAM client repository allowing you to run 'dumpbootstrap' and tell it which block to start the dump from. And since I had a bunch of .clam folders ready to go, I tested it:


ie. I have two clamd processes running. One is up to date and one is behind (and not connected to any peers). I create an 11-block bootstrap from the up to date clamd, copy it into the out of date clamd's date folder, restart, and see that it has successfully imported just those blocks. The 11 block bootstrap file was just 10642 bytes long.

So I'll publish 10k block bootstrap files, along with the big one. If you're 30k blocks behind, you can simply download the last three, append them all together in order (the format is simple enough that you can stick them end to end without breaking anything) and restart the client.

See the old bootstrap.dat post for details of how to find the 10k block bootstrap files.

Edit: presstab replied, then apparently deleted his reply. He made the point that there's no harm using a full bootstrap.dat file, because it will quickly skip the blocks you already have, and the only advantage of partial bootstrap files is they're smaller.

I was curious to know how long it takes to skip through a bootstrap file you've already imported, so I tried it:


It was taking 13 seconds per 10000 blocks up until around block 200k, and then it got much much faster. Why would that be? What happened around there?

I repeated the test to see if it would happen the same way, and it did:


tldr: it takes about 6 minutes, but skips the 2nd half much faster than the 1st half.

Edit: it's not because the blocks are smaller that they are skipped more quickly. If anything they're bigger:


Maybe this is a clue?


Edit: ok, case solved:


To tell whether we already have a block we find in a bootstrap file, we hash it and see if we have a block with that hash. Before block 203501 blocks were hashed using scrypt, which is designed to be slow. After block 203500 we switched to sha256 which is fast. Notice how blocks 0 and 10000 have hashes that start with a lot of zeroes - that's because they were proof-of-work blocks.