1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
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--
|
