Author: Jonas Schnelli 2017-11-27 20:49:07
Published on: 2017-11-27T20:49:07+00:00
A new member of the Bitcoin-dev mailing list, Jeff Johnson, has suggested a possible solution to increase the amount of data in a block without increasing its size on disk. By applying various compression algorithms, he was able to achieve approximately a 50% compression ratio on a recent Bitcoin block. He tested the raw block alongside Gzip, LZMA, ZStandard and LZ4 methods. Decompression time would matter more than the compression time as blocks will be decompressed billions of times more than they will be compressed. The fastest decompression speed among all the above methods is for LZ4 at 3.3GB / second, which is slightly less than half the speed of memcpy. If this solution were implemented in the Bitcoin protocol, there would need to be a place to specify the compression type in a set of bits somewhere, so that future compression algorithms could potentially be added. Miners could choose how many transactions they want to stuff into the block, keeping the compressed size under the limit. The bitcoin client code would also need to be able to handle the appropriate compression bits, and limits of signature data, etc. modified to deal with the compression. Schnorr signatures are on the roadmap as a 25% compression gain. It is thought that they could compress even further when compressed with the compression methods mentioned by Johnson. If bandwidth is a concern, then on the fly gzip compression like apaches mod_deflate could be applied. Bandwidth may be a concern for historical blocks transmission. If disk space is a concern, then the database layer should handle the compression. There have been previous discussions about similar approaches. However, it is not clear whether compression should be built into the protocol and it is suggested that it should be built into different layers. The link to Jeff's findings on a recent Bitcoin block can be found in the original message.
Updated on: 2023-06-12T22:20:51.184164+00:00