diff options
| author | Olaoluwa Osuntokun <laolu32@gmail.com> | 2017-06-09 03:50:37 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-06-09 03:50:50 +0000 |
| commit | 4f7f5137540b183c0722477fe0be3431d8d12887 (patch) | |
| tree | a3b0fb99c5821d3ad8e7eee2457d2b307f683046 | |
| parent | 110aeeb0ae647212d78eba3c1f954f7838fb581b (diff) | |
| download | pi-bitcoindev-4f7f5137540b183c0722477fe0be3431d8d12887.tar.gz pi-bitcoindev-4f7f5137540b183c0722477fe0be3431d8d12887.zip | |
Re: [bitcoin-dev] BIP Proposal: Compact Client Side Filtering for Light Clients
| -rw-r--r-- | df/49f0c3ad35f7c03740cdda2a51765b822b2b49 | 263 |
1 files changed, 263 insertions, 0 deletions
diff --git a/df/49f0c3ad35f7c03740cdda2a51765b822b2b49 b/df/49f0c3ad35f7c03740cdda2a51765b822b2b49 new file mode 100644 index 000000000..3dd237b2f --- /dev/null +++ b/df/49f0c3ad35f7c03740cdda2a51765b822b2b49 @@ -0,0 +1,263 @@ +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>> A rough estimate would in= +dicate this to be about 2-2.5x as big per block</div><div>> as your prop= +osal, but comes with rather different security</div><div>> 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>"downloading" you mean downloading all the blocks. Clients onl= +y need to</div><div>sync the block+filter headers, then (if they don't = +care about historical</div><div>blocks), will download filters from their &= +quot;birthday" onwards.</div><div><br></div><div>> The client could= + verify the TXIDs against the merkle root with a much</div><div>> strong= +er (PoW) guarantee compared to the guarantee based on the assumption</div><= +div>> of peers being distinct, which your proposal seems to make</div><d= +iv><br></div><div>Our proposal only makes a "one honest peer" 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're able to verify = +PoW conformance/work as normal.</div><div><br></div><div>> I don't c= +ompletely understand the benefit of making the outpoints and</div><div>>= + pubkey hashes (weakly) verifiable. These only serve as notifications and</= +div><div>> 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>> I think client-side filtering is definitely an= + important route to take,</div><div>> but is it worth compressing away t= +he information to verify the merkle</div><div>> root?</div><div><br></di= +v><div>That'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>> 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'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'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 "= +;hiding notifications"?<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-- + |