This is special to our use case:  bootstrap.dat is essentially an append-only file.  Blocks are simply concatenated onto the end.

((...snip...))

The next torrent, a few months from now, will have the same first 2,491,771,562 bytes.

Thus, to bittorrent, the next torrent will simply appear to be a truncated not fully downloaded bootstrap.dat.  Bittorrent is built to fill in the missing pieces of a file, so that is what it does here

Am I doing something wrong?  I've been seeding for over a month, but have had very little interest in it:



This is in 'transmission'.

There tends to be bursts, with idleness following.  There are many seeders, so download-then-idle is quite fast.

It has the most impact in handling unintended bursts, like when bitcoin sees a lot of new press attention.

Am I doing something wrong?  I've been seeding for over a month, but have had very little interest in it:



This is in 'transmission'.

This script is used to generate bootstrap.dat:
https://github.com/jgarzik/pynode/blob/master/mkbootstrap.py

It requires an up-to-date pynode chain database.

In theory, someone could write a script that processes bitcoind's $DATADIR/blocks directory into bootstrap.dat, but no one has written that yet.

it's a pity the torrent isn't 7zipped...

could the next iteration of it be compressed?

Feedback on this is welcomed.  Generally, not all platforms have an easy time getting up and running with 7zip.  Users in the past requested something directly usable with bitcoind.

Opinions differ, and maybe if it saves a gigabyte or two, it would be worth it.

Some users also complain about the doubling of disk space required -- for both compressed and uncompressed copies.

....
I am slowly convincing myself even more that a compressed torrent is preferable. 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+ 3000+ 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
(another: small split files easier to host/share/download from multiple sources than a single 8GB file)

Compressed-Cons:
-Not as simple to use, end-user must decompress with third-party utility (although 7-zip is common),
-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