Johnathan Corgan [ARCHIVE] on Nostr: π Original date posted:2015-11-09 π Original message:On Mon, Nov 9, 2015 at ...
π
Original date posted:2015-11-09
π Original message:On Mon, Nov 9, 2015 at 11:18 AM, Peter Tschipper via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I opened a PR #6973 this morning for Zlib Block Compression for block
> relay and at the request of @sipa this should have a BIP associated
> with it. The idea is simple, to compress the datastream before
> sending, initially for blocks only but it could theoretically be done
> for transactions as well. Initial results show an average of 20% block
> compression and taking 90 milliseconds for a full block (on a very slow
> laptop) to compress. The savings will be mostly in terms of less
> bandwidth used, but I would expect there to be a small performance gain
> during the transmission of the blocks particularly where network latency
> is higher.
>
βThe trade-off decisions among bandwidth savings, CPU performance, and
latency are local, and I think it shouldn't be assumed that any particular
node will want to support it. I recommend that if P2P message compression
is implemented, it should be negotiated via the services field at
connection time.
--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151109/ba80d6bb/attachment.html>
π Original message:On Mon, Nov 9, 2015 at 11:18 AM, Peter Tschipper via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I opened a PR #6973 this morning for Zlib Block Compression for block
> relay and at the request of @sipa this should have a BIP associated
> with it. The idea is simple, to compress the datastream before
> sending, initially for blocks only but it could theoretically be done
> for transactions as well. Initial results show an average of 20% block
> compression and taking 90 milliseconds for a full block (on a very slow
> laptop) to compress. The savings will be mostly in terms of less
> bandwidth used, but I would expect there to be a small performance gain
> during the transmission of the blocks particularly where network latency
> is higher.
>
βThe trade-off decisions among bandwidth savings, CPU performance, and
latency are local, and I think it shouldn't be assumed that any particular
node will want to support it. I recommend that if P2P message compression
is implemented, it should be negotiated via the services field at
connection time.
--
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151109/ba80d6bb/attachment.html>