diff options
| author | Pieter Wuille <pieter.wuille@gmail.com> | 2018-06-02 23:11:56 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-06-03 06:12:11 +0000 |
| commit | ab4f8401d625334739323b923f2b4ca380eed407 (patch) | |
| tree | e3dd1549737251d1f77c7e4bf781ee61a0f7aaaa | |
| parent | 996561ecc61b84ade2fb1b4927d46a0b6a98c18c (diff) | |
| download | pi-bitcoindev-ab4f8401d625334739323b923f2b4ca380eed407.tar.gz pi-bitcoindev-ab4f8401d625334739323b923f2b4ca380eed407.zip | |
Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size
| -rw-r--r-- | 57/f2eec00ca9265dcac089889ea6e1c0313b49fb | 187 |
1 files changed, 187 insertions, 0 deletions
diff --git a/57/f2eec00ca9265dcac089889ea6e1c0313b49fb b/57/f2eec00ca9265dcac089889ea6e1c0313b49fb new file mode 100644 index 000000000..86e638bb4 --- /dev/null +++ b/57/f2eec00ca9265dcac089889ea6e1c0313b49fb @@ -0,0 +1,187 @@ +Return-Path: <pieter.wuille@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 132B6E81 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 3 Jun 2018 06:12:11 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ot0-f171.google.com (mail-ot0-f171.google.com + [74.125.82.171]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 811612C4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 3 Jun 2018 06:12:10 +0000 (UTC) +Received: by mail-ot0-f171.google.com with SMTP id i5-v6so33922583otf.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 02 Jun 2018 23:12:10 -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 + :cc; bh=aP0YpRje1xY/P+uKp2nndc9dHqaXZ30X3vBeYgfEQxo=; + b=P/5Dopi+heisEmtrdN5XZoF096kaDLqNTgC+ZToOyG3KOW323zBBXLb0oQdh4pGm0D + SKHIYz0U2AdDFSyX9UaqDvCDmrS9V2zGKTJr9pMM+Ox5EzO/xm5DKa1uYdRl9ZLF1Y51 + uYQQgAxlfA6o+R0rl4ScTTG0JaOSIOpQFYCqUU3Oze5PV8OLejcOBRyWwduPmPofJ3Ta + ZdO6ac60612gewHdKuqNr3G2bWt4slMBdYt35ihl6uMZI5JphwdsGFodQMiZg23nOLEN + k7tzscLfmQgxlQhVNpYns7d2vm7pVRowvZM90tZBqht8rm9ifK6Kfley6u39jhOI6y8E + r44w== +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:cc; + bh=aP0YpRje1xY/P+uKp2nndc9dHqaXZ30X3vBeYgfEQxo=; + b=X0bxQuaN71P6ayZAefVgmzBzfC1+zx9mQm9iAftsxSWtw/RnugnRjdAMvRiUYLE50H + KW0908gcTF2A1XaBiiOCdjZt/XSffHpUgmvXgy14AY1mTgyVDHi2mzyiZpJnpxYtzfzT + IZYhj9BJTennPZnK5kiTniq5it+CD/J5ADYaooJiRVX0x/A4ij3ijuaqAG2N2F7h5plG + 1+mFWRKyp3dq7DTs/km/I2V6R236RetSnquUb15YxV8T26/SqZYS2yC9ww3RPrvbhhz6 + HzvT0IhQiYyNODnwopcBrh+2YmGTHzIH1RAoYgIvSRGI2BIyZocO/v4GPKqIaKpaDxPk + GX4w== +X-Gm-Message-State: APt69E1fx+niGmboTkERnk3fkPUhbmZeUd33uGyAyzqViVM+sK/Hqp23 + pc8TNaj3hcuKQGTSthBtfPfD3wkiuSvOBO6YLAw= +X-Google-Smtp-Source: ADUXVKL/dYlty/+DJJ59W1Gn0h3W+mrmzd0/0adTNDNbPyV2zNgmnjzHEmws9MQgNBb3c2X7vRX0C2FE2+GIF8dam9s= +X-Received: by 2002:a9d:124:: with SMTP id 33-v6mr6479767otu.65.1528006329611; + Sat, 02 Jun 2018 23:12:09 -0700 (PDT) +MIME-Version: 1.0 +References: <7E4FA664-BBAF-421F-8C37-D7CE3AA5310A@gmail.com> + <F87D7069-0FDC-4572-B02B-398A2A455935@gmail.com> + <CAAS2fgT716PiP0ucoASxryM9y+s9H2z06Z0ToaP1xT3BozAtNw@mail.gmail.com> + <CADZtCSguto2z6Z9CykymxnCokqo1G=sW0Ov0ht+KcD+KMnYyow@mail.gmail.com> + <CAO3Pvs-YDzfRqmyJ85wTH0ciccjCvkm5stGyP_tVGGna=PMv3A@mail.gmail.com> + <CAO3Pvs9p5COiS_7Jbj1r2iAKTEdXUcnVTRzL27c3=CeuB9WDTQ@mail.gmail.com> + <CAAS2fgSyVi0d_ixp-auRPPzPfFeffN=hsWhWT5=EzDO3O+Ue1g@mail.gmail.com> + <CAO3Pvs_0qCZbRCfL8EJw6gzWjZeXWcJrtg27g_SJ7+PkYTHg6A@mail.gmail.com> + <CAAS2fgTs+aKyiL8Kg_AZk=Mdh6896MEg=KHa6ANAZO7unsGEsg@mail.gmail.com> + <CADZtCShyYbgKk2zsKzQniqDw--XKfYWTk3Hk3o50V=MgT6zeuQ@mail.gmail.com> + <20180602124157.744x7j4u7dqtaa43@email> + <343A3542-3103-42E9-95B7-640DFE958FFA@gmail.com> + <CAAS2fgQDdJpzPR9Ve81hhyqU+MO7Ryy125fzK-iv=sfwwORDCw@mail.gmail.com> + <37BECD1A-7515-4081-85AC-871B9FB57772@gmail.com> +In-Reply-To: <37BECD1A-7515-4081-85AC-871B9FB57772@gmail.com> +From: Pieter Wuille <pieter.wuille@gmail.com> +Date: Sat, 2 Jun 2018 23:11:56 -0700 +Message-ID: <CAPg+sBjXbwTKW+qbGwJgau-Q2-uJC6N1JH8hH4KThv0Ah3WuqA@mail.gmail.com> +To: Tamas Blummer <tamas.blummer@gmail.com>, + Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="0000000000007db9d3056db6b28f" +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + RCVD_IN_DNSWL_NONE autolearn=ham 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 158 Flexibility and Filter Size +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: Sun, 03 Jun 2018 06:12:11 -0000 + +--0000000000007db9d3056db6b28f +Content-Type: text/plain; charset="UTF-8" + +On Sat, Jun 2, 2018, 22:56 Tamas Blummer via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Lighter but SPV secure nodes (filter committed) would help the network +> (esp. Layer 2) to grow mesh like, but add more user that blindly follow POW. +> +> On longer term most users' security will be determined by either trusted +> hubs or POW. +> I do not know which is worse, but we should at least offer the choice to +> the user, therefore commit filters. +> + +I don't think that's the point of discussion here. Of course, in order to +have filters that verifiably don't lie by omission, the filters need to be +committed to by blocks. + +The question is what data that filter should contain. + +There are two suggestions: +(a) The scriptPubKeys of the block's outputs, and prevouts of the block's +inputs. +(b) The scriptPubKeys of the block's outputs, and scriptPubKeys of outputs +being spent by the block's inputs. + +The advantage of (a) is that it can be verified against a full block +without access to the outputs being spent by it. This allows light clients +to ban nodes that give them incorrect filters, but they do need to actually +see the blocks (partially defeating the purpose of having filters in the +first place). + +The advantage of (b) is that it is more compact (scriot reuse, and outputs +spent within the same block as they are created). It also had the advantage +of being more easily usable for scanning of a wallet's transactions. Using +(a) for that in some cases may need to restart and refetch when an output +is discovered, to go test for its spending (whose outpoint is not known +ahead of time). Especially when fetching multiple filters at a time this +may be an issue. + +I think both of these potentially good arguments. However, once a committed +filter exists, the advantage of (a) goes away completely - validation of +committed filters is trivial and can be done without needing the full +blocks in the first place. + +So I think the question is do we aim for an uncommitted (a) first and a +committed (b) later, or go for (b) immediately? + +Cheers, + +-- +Pieter + +--0000000000007db9d3056db6b28f +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, = +Jun 2, 2018, 22:56 Tamas Blummer via bitcoin-dev <<a href=3D"mailto:bitc= +oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a= +>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0= + 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lighter but SPV secure= + nodes (filter committed) would help the network (esp. Layer 2) to grow mes= +h like, but add more user that blindly follow POW.<br> +<br> +On longer term most users' security will be determined by either truste= +d hubs or POW.<br> +I do not know which is worse, but we should at least offer the choice to th= +e user, therefore commit filters.<br></blockquote></div></div><div dir=3D"a= +uto"><br></div><div dir=3D"auto">I don't think that's the point of = +discussion here. Of course, in order to have filters that verifiably don= +9;t lie by omission, the filters need to be committed to by blocks.</div><d= +iv dir=3D"auto"><br></div><div dir=3D"auto">The question is what data that = +filter should contain.</div><div dir=3D"auto"><br></div><div dir=3D"auto">T= +here are two suggestions:</div><div dir=3D"auto">(a) The scriptPubKeys of t= +he block's outputs, and prevouts of the block's inputs.</div><div d= +ir=3D"auto">(b) The scriptPubKeys of the block's outputs, and scriptPub= +Keys of outputs being spent by the block's inputs.</div><div dir=3D"aut= +o"><br></div><div dir=3D"auto">The advantage of (a) is that it can be verif= +ied against a full block without access to the outputs being spent by it. T= +his allows light clients to ban nodes that give them incorrect filters, but= + they do need to actually see the blocks (partially defeating the purpose o= +f having filters in the first place).</div><div dir=3D"auto"><br></div><div= + dir=3D"auto">The advantage of (b) is that it is more compact (scriot reuse= +, and outputs spent within the same block as they are created). It also had= + the advantage of being more easily usable for scanning of a wallet's t= +ransactions. Using (a) for that in some cases may need to restart and refet= +ch when an output is discovered, to go test for its spending (whose outpoin= +t is not known ahead of time). Especially when fetching multiple filters at= + a time this may be an issue.</div><div dir=3D"auto"><br></div><div dir=3D"= +auto">I think both of these potentially good arguments. However, once a com= +mitted filter exists, the advantage of (a) goes away completely - validatio= +n of committed filters is trivial and can be done without needing the full = +blocks in the first place.</div><div dir=3D"auto"><br></div><div dir=3D"aut= +o">So I think the question is do we aim for an uncommitted (a) first and a = +committed (b) later, or go for (b) immediately?</div><div dir=3D"auto"><br>= +</div><div dir=3D"auto">Cheers,</div><div dir=3D"auto"><br></div><div dir= +=3D"auto">--=C2=A0</div><div dir=3D"auto">Pieter</div><div dir=3D"auto"><br= +></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gm= +ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= +ft:1ex"> +</blockquote></div></div></div> + +--0000000000007db9d3056db6b28f-- + |