Author: Matt Corallo 2015-12-04 13:30:33
Published on: 2015-12-04T13:30:33+00:00
In a Bitcoin developer mailing list, Matt Corallo expressed his concern over additional complexity and attack surface that may arise with the implementation of Lempel-Ziv (LZ) family of compressors, despite the minor 15 to 27% compression gain. He suggested that syncing over slow and/or very restrictive connections could be better addressed by a sync-over-http-via-cdn protocol than the p2p protocol. Peter Tschipper, however, argued that the larger the data, the better the compression, and that it would not be difficult to add compression since the feature can be completely turned off if there is an issue. Emin Gün Sirer then brought up the point that LZ family of compressors are generally based on "compression tables" which are nowhere as compact as they could possibly be for mostly binary data like the Bitcoin wire protocol. He suggested that a custom, Bitcoin-aware compressor can perhaps do significantly better than the generic compression algorithms, with much higher compression ratios of 2X or more possible in some cases. However, he also acknowledged that this could lead to difficulty in changing the wire format later on, making the protocol-agnostic, off-the-shelf compressors more maintainable at the expense of compression ratio. Nevertheless, he believed that given the amount of debate over block size, it seemed criminal to leave potentially free improvements on the table and that compressing Bitcoin could buy some additional throughput at zero cost, modulo code complexity. If Bitcoin were to be compressed, a programming challenge/contest was suggested as one of the best ways to find the best possible, Bitcoin-specific compressor. The results would be interesting even if the final compression engine is not enabled by default or not even merged.
Updated on: 2023-05-19T22:27:43.606110+00:00