MIME-Version: 1.0
In-Reply-To: <CADabwBBrrPM2f9h_sgxY12tg=FUvKKCcnCC8ixnct93YL9uEFQ@mail.gmail.com>
References: <CADabwBBrrPM2f9h_sgxY12tg=FUvKKCcnCC8ixnct93YL9uEFQ@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 28 Aug 2017 12:13:11 -0400
Message-ID: <CAB3F3DuK-5Bs-NunBVBnNbAT3SCVBZEqJqRHUHsSZhCVeO8xEQ@mail.gmail.com>
To: Riccardo Casatta <riccardo.casatta@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045c2a666c19d10557d293bf"
Subject: Re: [bitcoin-dev] "Compressed" headers stream
Precedence: list

--f403045c2a666c19d10557d293bf
Content-Type: text/plain; charset="UTF-8"

Is there any reason to believe that you need Bitcoin "full security" at all
for timestamping?

On Mon, Aug 28, 2017 at 11:50 AM, Riccardo Casatta via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi everyone,
>
> the Bitcoin headers are probably the most condensed and important piece of
> data in the world, their demand is expected to grow.
>
> When sending a stream of continuous block headers, a common case in IBD
> and in disconnected clients, I think there is a possible optimization of
> the transmitted data:
> The headers after the first could avoid transmitting the previous hash
> cause the receiver could compute it by double hashing the previous header
> (an operation he needs to do anyway to verify PoW).
> In a long stream, for example 2016 headers, the savings in bandwidth are
> about 32/80 ~= 40%
> without compressed headers 2016*80=161280 bytes
> with compressed headers 80+2015*48=96800 bytes
>
> What do you think?
>
>
> In OpenTimestamps calendars we are going to use this compression to give
> lite-client a reasonable secure proofs (a full node give higher security
> but isn't feasible in all situations, for example for in-browser
> verification)
> To speed up sync of a new client Electrum starts with the download of a
> file <https://headers.electrum.org/blockchain_headers> ~36MB containing
> the first 477637 headers.
> For this kind of clients could be useful a common http API with fixed
> position chunks to leverage http caching. For example /headers/2016/0
> returns the headers from the genesis to the 2015 header included while
> /headers/2016/1 gives the headers from the 2016th to the 4031.
> Other endpoints could have chunks of 20160 blocks or 201600 such that with
> about 10 http requests a client could fast sync the headers
>
>
> --
> Riccardo Casatta - @RCasatta <https://twitter.com/RCasatta>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">Is there any reason to believe that you need Bitcoin &quot=
;full security&quot; at all for timestamping?</div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Mon, Aug 28, 2017 at 11:50 AM, Riccard=
o Casatta via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoun=
dation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>Hi everyone,</div><div><br></div><div>the Bitcoin headers are=
 probably the most condensed and important piece of data in the world, thei=
r demand is expected to grow.</div><div><br></div><div>When sending a strea=
m of continuous block headers, a common case in IBD and in disconnected cli=
ents, I think there is a possible optimization of the transmitted data:</di=
v><div>The headers after the first could avoid transmitting the previous ha=
sh cause the receiver could compute it by double hashing the previous heade=
r (an operation he needs to do anyway to verify PoW).</div><div>In a long s=
tream, for example 2016 headers, the savings in bandwidth are about 32/80 ~=
=3D 40%</div><div>without compressed headers 2016*80=3D161280 bytes</div><d=
iv>with compressed headers 80+2015*48=3D96800 bytes</div><div><br></div><di=
v>What do you think?</div><div><br></div><div><br></div><div>In OpenTimesta=
mps calendars we are going to use this compression to give lite-client a re=
asonable secure proofs (a full node give higher security but isn&#39;t feas=
ible in all situations, for example for in-browser verification)</div><div>=
To speed up sync of a new client Electrum starts with the download of a <a =
href=3D"https://headers.electrum.org/blockchain_headers" target=3D"_blank">=
file</a>=C2=A0~36MB containing the first 477637 headers.=C2=A0</div><div>Fo=
r this kind of clients could be useful a common http API with fixed positio=
n chunks to leverage http caching. For example /headers/2016/0 returns the =
headers from the genesis to the 2015 header included while /headers/2016/1 =
gives the headers from the 2016th to the 4031.</div><div>Other endpoints co=
uld have chunks of 20160 blocks or 201600 such that with about 10 http requ=
ests a client could fast sync the headers</div><span class=3D"HOEnZb"><font=
 color=3D"#888888"><br clear=3D"all"><div><br></div>-- <br><div class=3D"m_=
6184025682653505407gmail_signature"><div dir=3D"ltr">Riccardo Casatta - <a =
href=3D"https://twitter.com/RCasatta" target=3D"_blank">@RCasatta</a></div>=
</div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--f403045c2a666c19d10557d293bf--