MIME-Version: 1.0
References: <CAO3Pvs8ccTkgrecJG6KFbBW+9moHF-FTU+4qNfayeE3hM9uRrg@mail.gmail.com>
	<1496915408.1583369.1002689000.641E8EAB@webmail.messagingengine.com>
In-Reply-To: <1496915408.1583369.1002689000.641E8EAB@webmail.messagingengine.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Fri, 09 Jun 2017 03:50:37 +0000
Message-ID: <CAO3Pvs_0r1xOL9JMSXf7taG-vFcOanPEh7d4nuQKEPSNLZ6kXQ@mail.gmail.com>
To: Tomas <tomas@tomasvdw.nl>, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="001a114925f0ee095305517edfeb"
Subject: Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for
 Light Clients
Precedence: list

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

Tomas wrote:
> A rough estimate would indicate this to be about 2-2.5x as big per block
> as your proposal, but comes with rather different security
> characteristics, and would not require download since genesis.

Our proposal _doesnt_ require downloading from genesis, if by
"downloading" you mean downloading all the blocks. Clients only need to
sync the block+filter headers, then (if they don't care about historical
blocks), will download filters from their "birthday" onwards.

> The client could verify the TXIDs against the merkle root with a much
> stronger (PoW) guarantee compared to the guarantee based on the assumption
> of peers being distinct, which your proposal seems to make

Our proposal only makes a "one honest peer" assumption, which is the same
as any other operating mode. Also as client still download all the
headers, they're able to verify PoW conformance/work as normal.

> I don't completely understand the benefit of making the outpoints and
> pubkey hashes (weakly) verifiable. These only serve as notifications and
> therefore do not seem to introduce an attack vector.

Not sure what you mean by this. Care to elaborate?

> I think client-side filtering is definitely an important route to take,
> but is it worth compressing away the information to verify the merkle
> root?

That's not the case with our proposal. Clients get the _entire_ block (if
they need it), so they can verify the merkle root as normal. Unless one of
us is misinterpreting the other here.

-- Laolu


On Thu, Jun 8, 2017 at 6:34 AM Tomas via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Jun 1, 2017, at 21:01, Olaoluwa Osuntokun via bitcoin-dev wrote:
>
> Hi y'all,
>
> Alex Akselrod and I would like to propose a new light client BIP for
> consideration:
>    *
> https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki
>
>
>
> Very interesting.
>
> I would like to consider how this compares to another light client type
> with rather different security characteristics where each client would
> receive for each transaction in each block,
>
> * The TXID (uncompressed)
> * The spent outpoints (with TXIDs compressed)
> * The pubkey hash (compressed to reasonable amount of false positives)
>
> A rough estimate would indicate this to be about 2-2.5x as big per block
> as your proposal, but comes with rather different security characteristics,
> and would not require download since genesis.
>
> The client could verify the TXIDs against the merkle root with a much
> stronger (PoW) guarantee compared to the guarantee based on the assumption
> of peers being distinct, which your proposal seems to make. Like your
> proposal this removes the privacy and processing  issues from server-side
> filtering, but unlike your proposal retrieval of all txids in each block
> can also serve for a basis of fraud proofs and (disprovable) fraud hints,
> without resorting to full block downloads.
>
> I don't completely understand the benefit of making the outpoints and
> pubkey hashes (weakly) verifiable. These only serve as notifications and
> therefore do not seem to introduce an attack vector. Omitting data is
> always possible, so receiving data is a prerequisite for verification, not
> an assumption that can be made.  How could an attacker benefit from "hiding
> notifications"?
>
> I think client-side filtering is definitely an important route to take,
> but is it worth compressing away the information to verify the merkle root?
>
> Regards,
> Tomas van der Wansem
> bitcrust
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>Tomas wrote:</div><div>&gt; A rough estimate would in=
dicate this to be about 2-2.5x as big per block</div><div>&gt; as your prop=
osal, but comes with rather different security</div><div>&gt; characteristi=
cs, and would not require download since genesis.=C2=A0</div><div><br></div=
><div>Our proposal _doesnt_ require downloading from genesis, if by</div><d=
iv>&quot;downloading&quot; you mean downloading all the blocks. Clients onl=
y need to</div><div>sync the block+filter headers, then (if they don&#39;t =
care about historical</div><div>blocks), will download filters from their &=
quot;birthday&quot; onwards.</div><div><br></div><div>&gt; The client could=
 verify the TXIDs against the merkle root with a much</div><div>&gt; strong=
er (PoW) guarantee compared to the guarantee based on the assumption</div><=
div>&gt; of peers being distinct, which your proposal seems to make</div><d=
iv><br></div><div>Our proposal only makes a &quot;one honest peer&quot; ass=
umption, which is the same</div><div>as any other operating mode. Also as c=
lient still download all the</div><div>headers, they&#39;re able to verify =
PoW conformance/work as normal.</div><div><br></div><div>&gt; I don&#39;t c=
ompletely understand the benefit of making the outpoints and</div><div>&gt;=
 pubkey hashes (weakly) verifiable. These only serve as notifications and</=
div><div>&gt; therefore do not seem to introduce an attack vector.</div><di=
v><br></div><div>Not sure what you mean by this. Care to elaborate?=C2=A0</=
div><div><br></div><div>&gt; I think client-side filtering is definitely an=
 important route to take,</div><div>&gt; but is it worth compressing away t=
he information to verify the merkle</div><div>&gt; root?</div><div><br></di=
v><div>That&#39;s not the case with our proposal. Clients get the _entire_ =
block (if</div><div>they need it), so they can verify the merkle root as no=
rmal. Unless one of</div><div>us is misinterpreting the other here.</div><d=
iv><br></div><div>-- Laolu</div><div><br></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr">On Thu, Jun 8, 2017 at 6:34 AM Tomas via bitcoin-dev &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div><div>On Thu, Jun 1, 2017, at 21:01, Olaoluwa Osuntokun via bitcoin-d=
ev wrote:<br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div>Hi y&#39;all,=C2=A0<br></di=
v>
<div><br></div>
<div>Alex Akselrod and I would like to propose a new light client BIP for<b=
r></div>
<div>consideration:=C2=A0<br></div>
<div>=C2=A0 =C2=A0* <a href=3D"https://github.com/Roasbeef/bips/blob/master=
/gcs_light_client.mediawiki" target=3D"_blank">https://github.com/Roasbeef/=
bips/blob/master/gcs_light_client.mediawiki</a><br></div>
<div><br></div>
<div><br></div>
</div>
</blockquote><div><br></div>
</div><div><div>Very interesting. <br></div>
<div><br></div>
<div>I would like to consider how this compares to another light client typ=
e with rather different security characteristics where each client would re=
ceive for each transaction in each block, <br></div>
<div><br></div>
<div>* The TXID (uncompressed)<br></div>
<div>* The spent outpoints (with TXIDs compressed)<br></div>
<div>* The pubkey hash (compressed to reasonable amount of false positives)=
<br></div>
<div><br></div>
<div>A rough estimate would indicate this to be about 2-2.5x as big per blo=
ck as your proposal, but comes with rather different security characteristi=
cs, and would not require download since genesis. <br></div>
<div><br></div>
<div>The client could verify the TXIDs against the merkle root with a much =
stronger (PoW) guarantee compared to the guarantee based on the assumption =
of peers being distinct, which your proposal seems to make. Like your propo=
sal this removes the privacy and processing=C2=A0 issues from server-side f=
iltering, but unlike your proposal retrieval of all txids in each block can=
 also serve for a basis of  fraud proofs and (disprovable) fraud hints, wit=
hout resorting to full block downloads.<br></div>
<div><br></div>
<div>I don&#39;t completely understand the benefit of making the outpoints =
and pubkey hashes (weakly) verifiable. These only serve as notifications an=
d therefore do not seem to introduce an attack vector. Omitting data is alw=
ays possible, so receiving data is a prerequisite for verification, not an =
assumption that can be made.=C2=A0 How could an attacker benefit from &quot=
;hiding notifications&quot;?<br></div>
<div><br></div>
<div>I think client-side filtering is definitely an important route to take=
, but is it worth compressing away the information to verify the merkle roo=
t?<br></div>
<div><br></div>
<div>Regards,<br></div>
<div>Tomas van der Wansem<br></div>
<div>bitcrust<br></div>
<div><br></div>
</div>

_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--001a114925f0ee095305517edfeb--