path: root/df/49f0c3ad35f7c03740cdda2a51765b822b2b49

Return-Path: <laolu32@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0143E722
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Jun 2017 03:50:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com
	[209.85.161.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 032F5A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Jun 2017 03:50:48 +0000 (UTC)
Received: by mail-yw0-f179.google.com with SMTP id 63so18015984ywr.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 08 Jun 2017 20:50:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=YIj+feVYejOCzGqJc0XLcZ/WS+iYs6SQhl5FtsbZebk=;
	b=KC4IOzffOHeDWs+7ezwDfTWiSVxlIgjUs0jrYzdUbik/ozG+DGUhHSDH+1bMOB8XCs
	BkrE9/FsjoDReEL7jnxAJnm32hK6223OYohmQN++nRd5ZWAgBcvYmYjxuj8/QUTjlW+O
	O7t4npIUM4aiopJt1nnKzvftcz6kCvKwWzMJLoKD0ijJMTfQFn81LgRLawCOTS59Fwkp
	CN4kUs18dVUeFsyAhVCnX6lySrqQleH2U3oZC8nomWE6xrOtm/2hogCKlHfwld29X9m7
	j+2iJ+4pHmU1lWDPzjDac9g4aghOKnVajTJZ98V1MuEXAQTdeav17ZpIiywTdA7iYEhC
	B/hQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=YIj+feVYejOCzGqJc0XLcZ/WS+iYs6SQhl5FtsbZebk=;
	b=LjWjVaUMYeHuny5QQEXAmigMpLQ25orJ4NTRowags9jXHAM8pjq7oj7DNluRDifDIM
	8exIPGLCLbhFpaWrp4fbKAbTUktUf69PvCoazeS3LXRe7IWTaJLBjrd+HkKg5GEi/WaP
	vtrtYj0NlYwZdVL729qeSsSEvJ5xf+wWIUIaGgs9H7JvoZ9Yo0Uyv21IkfrISJxm/Aoa
	OCkwFSOiovaJLELbHEiXMHMQrXlaSlNoX1Ix3v9i8xISS5wAswV8KwQ1Fo/rmGv2UUTW
	g3+Z1+rbB5JfrfuEQ6q/LjaXQTCt4kwX5c4mLV5LG2HpjmfUlBBcOm5gVMA/I/ncZ3vg
	xRAg==
X-Gm-Message-State: AODbwcClwdLzxiBaN6X9pwzrdmPtEzql67FJGv/JpvKDXR10QNgyo54E
	8INgVfUewo71hxUiTM3AekkGKtVE5Ss8
X-Received: by 10.129.88.138 with SMTP id m132mr13838303ywb.22.1496980248199; 
	Thu, 08 Jun 2017 20:50:48 -0700 (PDT)
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"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for
 Light Clients
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jun 2017 03:50:50 -0000

--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--