That may be problem with your client or firewall. I'm seeding only since yesterday evening and now it has > 300M uploaded already, using Deluge 1.3.5 .

Two ideas for improvement:

1) Compression: this will easy shave off 25% of the file size. My 2.6 G blockchain file uncompressed became 1.9 G compressed with zip.

2) Split it up in multiple files. If I stop using bitcoin for a couple of months and then start using it again I might still have a large chunk of the blockchain left on my computer. I really only need the new block. The current mainline has a new way of storing blockfiles (.bincoin/blocks/blk000?.dat instead of .bitcoin/blk000?.dat) each with size 128 MB (instead of the much larger .bitcoin/blk000?.dat files). These smaller, 128 MB, files would be nice to have available via a torrent, making it possible to limit the download to only the latest blocks.

There's allot of pseudorandom data in the blockchain that can't be compressed, so I don't know if there will be so much difference in the file size result between different algorithms in this case, maybe we can shave off another 100 MB with a better one. It would be interesting to see a comparison you linked to with the blockchain.

Oh, they're getting stored in a simple flat file. Well that's easy, download blocks from random peers and store them in temporary files. Then when the next block needed has been downloaded, copy it to the final block file.

blkindex.dat is not included in the torrent because that conflicts with Bitcoin's trust model.

If you're going to trust a single someone to do the indexing for you, you may as well trust the network (far less trust required) and run an SPV node (like Multibit). The purpose of the reference client is to be zero trust - not relying on any trusted data. If someone would distributed a faulty (intentional or not) set of block files with included index, and many people - in particular miners - would start using this data without verification, they could end up in a block chain fork if a transactions was included in a legitimate block that conflicts with their index.

Also, 0.8 will switch to an entirely different database layout (there won't be a blkindex.dat anymore), and validate blocks much faster (in particular when they're read from the local disk).

In checkpoints.cpp there is another checkpoint at 210000 - please update the torrent!

By the way, from time to time people still are using this (I'm a more or less permanent seeder here), so I guess the experiment is working.

I'll move this over here for more discussion of Torrent 2.0


"The 2GB issue", failure to import blocks after 2.0GiB on 32 bit builds, was reported by me, so I guess I'm the one that "raised" it here. Now that Bitcoin can actually use a bigger torrent and 0.8.0 has a higher checkpoint, it's finally time for a new torrent!

You should get the same 4.8GB bootstrap.dat SHA256 at that height, if you don't, we've got a big problem!

The only thing that would make a torrent I create less than "semi-official" would be if I make a compressed torrent without consensus. I am slowly convincing myself even more that a compressed torrent is preferable though. Without compression you are downloading the same amount of data as normal p2p. The compressed binary would only be repeatable on the exact xz/lzma/7zip build version and settings, but I think there are probably four people total that have run mkbootstrap anyway, so this is not important. It takes about an hour to smash the blockchain down to 60% the size at the extreme settings I've used over many trials to optimize settings.

Compressed-Pros:
-2000+ MB of uploading and downloading saved for every user,
-2000+ MB less storage used when seeding,
-won't cause problems if torrent HDD is FAT32 (under 4.0GB for now)

Compressed-Cons:
-Not as simple to use, end-user must decompress with third-party utility (although 7-zip is common and opens xz),
-More work creating torrent (doesn't matter to end-users),
-Cannot "update" torrent by simply replacing data file with newer version with additional blocks (likely to be a rare practice anyway, I am the only one seeding the old torrent right now).

Here is example compression, both require about an hour (but decompress in minutes):

xz utils 5.0.4/Win64, 3GB+ RAM required to compress (2,780,285,148 bytes)
xz --compress --keep --format=xz --check=sha256 --verbose --lzma2=dict=256MiB,nice=273,mf=bt4 bootstrap.dat

7-zip GUI win64 - 6GB+ RAM required to compress (2,769,830,975 bytes)
Format: 7z, Compression Level: Ultra, Compression method: LZMA, Dictionary size: 384MB, Word Size 273

Yep, your magnet link didn't get me anything.  I had to add some open trackers until I found some peers.

Anyway, I'll be seeding.

Here is a magnet link with a few good trackers added:

Oh, for anyone already seeding/downloading the old torrent:
Just remove the seed, open the new torrent and add it at the same location. Your torrent client then verifies the already existing blocks (~first 51.3% of the new torrent) and then loads the rest from other peers.

Well, I see 15 seeders and 9 leechers on the current (larger) bootstrap.dat file. Maybe you are not using trackers and/or mainlineDHT or using some restrictive firewall? Also download of the torrent was reasonably fast (= ~380 kB/s on average for the remaining 2.2 GB).

As long as BitcoinQT cannot handle a compressed bootstrap.dat.xz file, I'd rather waste some bandwidth instead of confusing newies even more.