Author: Peter Tschipper 2015-11-10 16:17:40
Published on: 2015-11-10T16:17:40+00:00
The Bitcoin network's protocol is important and two implementations of the decompressor might not be bug for bug compatible. This could potentially fork the network. A "raw" network library is less likely to have the same problem. To avoid this issue, compressing only block messages by creating a new "cblock" message could be considered. However, the compression could be applied to any datastream but is not forced. The compression should be applied to blocks and possibly transactions only if worthwhile and only if compression is turned on. Using the code in the PR to compress/decompress blocks using zlib compression level = 6, there are some benefits even below 10KB block size. If a client fails to decode a cblock, then it can ask for the block to be re-sent as a standard "block" message. This is purely a performance improvement. If problems occur, then the client can switch back to uncompressed mode for that block. There are better ways of sending new blocks, but for sending historical blocks and sending transactions, this PR is designed to save bandwidth and not intended to be a huge performance improvement in terms of time spent sending. Such trade-off decisions should be local and negotiated between peers, not a required feature of the network P2P. This reinforces the idea that such trade-off decisions should be local and negotiated between peers, not a required feature of the network P2P.
Updated on: 2023-06-11T00:59:47.932107+00:00