I'll move this over here for more discussion of Torrent 2.0
The blockchain checkpoint in this release has been updated to 216116. I created a bootstrap.dat of this height and successfully imported it in 37 minutes with bitcoin-qt on Win7 64 bit.
02/10/2013 08:44 PM 4,855,459,871 bootstrap.dat
SHA256: bf658c7055b733bfc15ea167f298c5599b89d220b14dbe7c8ef20b18e468c451 *bootstrap.dat
2013-02-11 06:35:35 SetBestChain: new best=00000000000000f97afdf8ccba49919bb998313ec67e3654798b86a3f6631c1e height=216115 work=714383275301559958540 tx=11010714 date=2013-01-11 10:59:18
2013-02-11 06:35:35 ProcessBlock: ACCEPTED
2013-02-11 06:35:36 SetBestChain: new best=00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e height=216116 work=714397232223717792651 tx=11011160 date=2013-01-11 11:11:30
2013-02-11 06:35:36 ProcessBlock: ACCEPTED
2013-02-11 06:35:36 Loaded 216116 blocks from external file in 2218342ms
I will offer this as a torrent and also give direct-download links to those who wish to jump-start and seed such a torrent, since my seeding speed is limited. The question is, should an official torrent going forward be a compressed file? Using the highest compression preset with
xz/lzma (installed with most distros, opens with 7-zip or
MacOS GUI tools) saves 2GB of downloading, so I say yes:
Also, bootstrap.dat is too big for FAT32, but not the compressed version. Bitcoin 0.9+ could even (feature request) open a compressed bootstrap (lzma is a stream container) directly if standardized.
The semi-official bootstrap.dat torrent is about to be updated, as it is for each bitcoin release. The 2GB issue has already been raised in that thread, and the FAT32 4GB issue would also be a good one to raise.
Ideally we would like everyone to seed the same torrent -- it's the same data, as guaranteed by bitcoin (as well as torrent) hashes.
"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.dat7-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
