One point to add here is that, while V1 non-encrypted p2p traffic could be compressed on a different OSI layer in theory, v2 encrypted traffic – due to its pseudorandom nature – will likely have no size savings and thus need to be compressed on the application layer with a proposal like this.
Would be nice to see size comparison of this compression proposal vs LZO/gzip compression of legacy transaction encoding. A possible advantage of this proposal is that it could save more space with less CPU impact, which might be important for block propagation. Previous discussion about compressing blocks before sending them: https://github.com/bitcoin/bitcoin/pull/6973 /jonas > Am 16.01.2024 um 18:08 schrieb Tom Briar via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org>: > > Hi, > > In addition to the use cases listed in the schema, such as steganography, > satellite, and radio broadcast, an application can be made for Peer-to-peer > communication between Bitcoin nodes. Except when compressing the Txid/Vout, > which is optional, Transactions can gain up to 30% size savings while still > being completely reversible. Furthermore, in a BIP-324 world, these savings > are nontrivial. > > BIP-324: https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki > Compressed Transaction Schema: compressed_transactions.md > > Thanks- > Tom. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
