Compress transaction log #2278

The bitcoin client data is quite heavy on disk, Right now 9,5 GB in my .bitcoin directory. Doing a "zip blk0001.dat.zip blk0001.dat" will reduce size 25%

This might actually be a good idea. IIRC, ZIP files support random access (unlike gzip and bzip2).

25% savings on diskspace is "meh" to me, I vote no. Disk space is cheap, development and testing time is expensive.

zip random access only works per file, not arbitrarily. It requires restarting the compression per file, which would probably shoot the compression amounts to heck. If we wanted to compress blocks we could probably do much faster (more compression with less cpu) doing something that understood the format. I expect most of the gain for block at a time compression right now comes from capturing repeated pubkeys.

Disk space doesn't come cheap on SSD. It depends if it can be done rather transparently... like pipe through zip upon load/save. Hybrid is to only zip the "full" block data files that won't be modified anyway. Like unix system log rotation.

Agree with @gavinandresen . I've done some work with random access to compressed data in the past and IMO it's not worth the complexity in the case of bitcoin, especially if the savings is only 25% in the best case (without re-positioning structures and/or extra block resets). On devices with limited storage space you don't want to run a full node in the first place.

I'm going to close this as "we've got much higher priority things to work on"

If you feel like experimenting, you might try linking the 0.8.0-release's .bitcoin/blocks/ to a directory on a fuser-zip filesystem (fuser-zip is a filesystem stored in a .zip file).