MIME-Version: 1.0
In-Reply-To: <5640F172.3010004@gmail.com>
References: <5640F172.3010004@gmail.com>
From: Johnathan Corgan <johnathan@corganlabs.com>
Date: Mon, 9 Nov 2015 12:41:17 -0800
Message-ID: <CALOxbZubcT63VHFowdJBBTziHfVV1qnBEREMa+3ctnRRBzf-cg@mail.gmail.com>
To: Peter Tschipper <peter.tschipper@gmail.com>
Content-Type: multipart/alternative; boundary=001a114057cc9eb2c60524219eba
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] request BIP number for: "Support for Datastream
	Compression"
Precedence: list

--001a114057cc9eb2c60524219eba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 9, 2015 at 11:18 AM, Peter Tschipper via bitcoin-dev <
bitcoin-dev@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.
>

=E2=80=8BThe 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.

--=20
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com

--001a114057cc9eb2c60524219eba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">On =
Mon, Nov 9, 2015 at 11:18 AM, Peter Tschipper via bitcoin-dev <span dir=3D"=
ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br></d=
iv><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">I opened a PR #6973 this morning for Zlib Blo=
ck Compression for block<br>
relay and at the request of @sipa=C2=A0 this should have a BIP associated<b=
r>
with it.=C2=A0 =C2=A0The idea is simple, to compress the datastream before<=
br>
sending, initially for blocks only but it could theoretically be done<br>
for transactions as well.=C2=A0 Initial results show an average of 20% bloc=
k<br>
compression and taking 90 milliseconds for a full block (on a very slow<br>
laptop) to compress.=C2=A0 The savings will be mostly in terms of less<br>
bandwidth used, but I would expect there to be a small performance gain<br>
during the transmission of the blocks particularly where network latency<br=
>
is higher.<br></blockquote><div><br></div><div><div class=3D"gmail_default"=
 style=3D"font-size:small">=E2=80=8BThe trade-off decisions among bandwidth=
 savings, CPU performance, and latency are local, and I think it shouldn=
9;t be assumed that any particular node will want to support it.=C2=A0 I re=
commend that if P2P message compression is implemented, it should be negoti=
ated via the services field at connection time.</div></div><div><br></div><=
/div>-- <br><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=3D"ltr"><d=
iv dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div>Johnathan Corgan<br>C=
organ Labs - SDR Training and Development Services</div><div><a href=3D"htt=
p://corganlabs.com" style=3D"font-size:12.8px" target=3D"_blank">http://cor=
ganlabs.com</a><br></div></div></div></div></div></div></div></div></div>
</div></div>

--001a114057cc9eb2c60524219eba--