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
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
|
Return-Path: <jim.posen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BAEAE1642
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Jun 2018 02:02:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f195.google.com (mail-qt0-f195.google.com
[209.85.216.195])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E3B79136
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Jun 2018 02:02:50 +0000 (UTC)
Received: by mail-qt0-f195.google.com with SMTP id y89-v6so9043943qtd.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 01 Jun 2018 19:02:50 -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=sIJ0v/V/Wuilj+A0iUqiYexrS20egilzl/wJ9Lqg41s=;
b=LNHm4T76h03whQYT2CQiPWYlU4/0vWVhi2K7DwbdPN9kzt/Pt6uvNe1YpZjAvBa5VR
kOhvtIFkfN9nvZW2g0TGNs15c8JNNATWiHiBRH6i74ArSNqGpDeb5N3QvOCRWGAmfrae
qXZkQoD/+NUT6Ex4IhF5qXTbbEvTFZlLWxE+8rSz079opOHepFcQo8uaNmUwgtktu5Av
vTno04m3KHIoGVQY+qXNdBqm2p8LRWidgY1ALBO0e7U9cs5mwFF2c5pC5a1L3ANX0CYm
GhZCdOl25WL5MiinPXhmGZa+FxZUP/VTuZn4oh6vciYv9pRsevdC4p10V5bTPj6KR4uq
+lww==
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=sIJ0v/V/Wuilj+A0iUqiYexrS20egilzl/wJ9Lqg41s=;
b=c8fnMxVlktuebAQpkEBAWUSPsi1ZP+CEdkDuZfdZn6EB9acVLH1j/eyH6cqsIPOV1e
r8jgG+rA/0GB3nWaJvCDZ4qiKe15fxOoZTVj9dF/AbWIKXDqsA0ujAJw0KV5DIf0T+Bd
glrFJ9LYudg21rDeY7xD1/dvQLSeCrpnWKxgP8OYW89Owrk2gplmcl9w1HrmF4fKXUYE
S2qeS/p0k5vFjgQzmqaGrdy82v+sze7Y42ZUP+N+o2l75m6ppVFxtcr1+Zs4FKrNRdW3
BE5XP4PZmj7rYXks1FaG7F4Z+x0550ec2W+BUdRSVtFisuSXV3IkfjjvwiLEpKT/IkBM
uwUg==
X-Gm-Message-State: APt69E0NOvWvxTwpkSS2xn86sbphrpW6SGGn/CGrU4YAylddBe1tPt+d
rf462M5c2sfyzSCckMYz1HD6BN9vTSSULF5vMAQ=
X-Google-Smtp-Source: ADUXVKI8I/Vdq3Az4gCNEpYppLPWKX3zdBz86H18LuiV8fODB6gLkX01/iHxEmA1tx1mzfw7BPzMXhKwimH6++VgNLI=
X-Received: by 2002:ac8:2f47:: with SMTP id
k7-v6mr13192156qta.363.1527904969906;
Fri, 01 Jun 2018 19:02:49 -0700 (PDT)
MIME-Version: 1.0
References: <d43c6082-1b2c-c95b-5144-99ad0021ea6c@mattcorallo.com>
<CAAS2fgRF-MhOvpFY6c_qAPzNMo3GQ28RExdSbOV6Q6Oy2iWn1A@mail.gmail.com>
<22d375c7-a032-8691-98dc-0e6ee87a4b08@mattcorallo.com>
<CAAS2fgR3QRHeHEjjOS1ckEkL-h7=Na56G12hYW9Bmy9WEMduvg@mail.gmail.com>
<CADZtCShLmH_k-UssNWahUNHgHvWQQ1y638LwaOfnJEipwjbiYg@mail.gmail.com>
<CAAS2fgQLCN_cuZ-3QPjCLfYOtHfEk=SenTn5=y9LfGzJxLPR3Q@mail.gmail.com>
<CADZtCSjYr6VMBVQ=rx44SgRWcFSXhVXUZJB=rHMh4X78Z2eY1A@mail.gmail.com>
<CAO3Pvs9K3n=OzVQ06XGQvzNC+Aqp9S60kWM9VRPA8hWTJ3u9BQ@mail.gmail.com>
<c23a5346-9f99-44f0-abbf-d7e7979bf1d8@gmail.com>
<CAO3Pvs_MA4TtgCCu1NgCBjK2bZRN+rKnGQJN6m4yTrViBXRiPA@mail.gmail.com>
<CAD3i26BibcaMdbQv-j+Egz_1y0GuhzepBp5ATNpj=Qv8hi1TVA@mail.gmail.com>
<CADZtCShAYpbN=4qNoX5c8yd1j08+mEZzG8gZwcHrj2suY0mb9w@mail.gmail.com>
<CADZtCShYnM3A949H18V2+BArA-K9J+cDkd=rX8xRn0+0js5CwA@mail.gmail.com>
<CAAS2fgTXS5Tains7dfe_Rc9JxR6M=NuFW9UtieRELm+6N2uNog@mail.gmail.com>
<CAFfwr8F+ghYb2HYEgC7Lh7Z-ytNE7EABr6cxiVXYhWLk-TPO7A@mail.gmail.com>
<CADZtCShDzPK_jqeOrK4XBoB2uriU9c9T8Dm7By-8ew3XOoAeQg@mail.gmail.com>
<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>
In-Reply-To: <CAAS2fgTs+aKyiL8Kg_AZk=Mdh6896MEg=KHa6ANAZO7unsGEsg@mail.gmail.com>
From: Jim Posen <jim.posen@gmail.com>
Date: Fri, 1 Jun 2018 19:02:38 -0700
Message-ID: <CADZtCShyYbgKk2zsKzQniqDw--XKfYWTk3Hk3o50V=MgT6zeuQ@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="000000000000fb5fe3056d9f18ba"
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
X-Mailman-Approved-At: Sat, 02 Jun 2018 02:04:45 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Sat, 02 Jun 2018 02:02:52 -0000
--000000000000fb5fe3056d9f18ba
Content-Type: text/plain; charset="UTF-8"
To address the at-least-one-honest peer security assumption for light
clients, I think this is a rather good security model for light clients.
First it significantly reduces the chances that an attacker can eclipse a
client just by chance, and clients can implement measures like ensuring
connectivity to peers from different subnets. But even if, as you suggest,
a network attacker controls the target's local network, peers still can
have good security guarantees by requiring authenticated connections to
semi-trusted peers. A client can select a set of N servers that it believes
will not collude to attack it, and only sync filters if connected to a
threshold of them. So even if the network is malicious, the attacker cannot
forge the authenticated responses. The level of trust in these designated
parties again is quite low because only one has to be honest. This would
require something like BIP 150.
Even if clients are uncomfortable with whitelisting required peers, it
could have a policy of requiring a certain number of connections to peers
that have honestly served it filters in the past. This is sort of like
trust-on-first-use. This type of scheme, however, would require nodes to
advertise a pubkey per address, which BIP 150/151 does not support at
present.
All in all, I think this is an acceptable security model for light clients.
Without the ability to verify filter validity, a client would have to stop
syncing altogether in the presence of just one malicious peer, which is
unacceptable.
The other concern you raise, Greg, is using a filter for P2P communications
that we expect may be replaced in the future. You also raise the point that
full node wallets can use the smaller filters for rescans because the
filter validity is not in question. I'd perfectly fine with the idea of
defining two filter types in the BIP, one that is output script + outpoint
and the other output script + prev script. But I imagine some people would
object to the idea of full nodes storing two different filters that overlap
in contents. If we had to pick just one though, I'm strongly in support of
output script + outpoint so that BIP 157 can be deployed ASAP without a
consensus change. It's entirely possible we will learn even more about
optimal filter design through deployment and adoption.
On Fri, Jun 1, 2018 at 5:22 PM Gregory Maxwell <greg@xiph.org> wrote:
> On Sat, Jun 2, 2018 at 12:01 AM, Olaoluwa Osuntokun <laolu32@gmail.com>
> wrote:
> >> A typical network attacker (e.g. someone on your lan or wifi segmet, or
> >> someone who has compromised or operates an upstream router) can be all
> of
> >> your peers.
> >
> > This is true, but it cannot make us accept any invalid filters unless the
> > attacker is also creating invalid blocks w/ valid PoW.
>
> I wish that were the true, but absent commitments that wouldn't be the
> case unless you were always downloading all the blocks-- since you
> wouldn't have any sign that there was something wrong with the
> filter-- and downloading all the blocks would moot using the filters
> in the first place. :)
>
> Or have I misunderstood you massively here?
>
> For segwit originally I had proposed adding additional commitments
> that would make it possible to efficiently prove invalidity of a
> block; but that got stripped because many people were of the view that
> the "assume you have at least one honest peer who saw that block and
> rejected it to tell you that the block was invalid" security
> assumption was of dubious value. Maybe it's more justifiable to make
> use of a dubious assumption for a P2P feature than for a consensus
> feature? Perhaps, I'd rather have both filter types from day one so
> that things not implementing the comparison techniques don't get the
> efficiency loss or the extra work to change filter types for a
> consensus one.
>
> [I think now that we're much closer to a design that would be worth
> making a consensus committed version of than we were a few months ago
> now, since we are effectively already on a second generation of the
> design with the various improvements lately]
>
--000000000000fb5fe3056d9f18ba
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To address the at-least-one-honest peer security assumptio=
n for light clients, I think this is a rather good security model for light=
clients. First it significantly reduces the chances that an attacker can e=
clipse a client just by chance, and clients can implement measures like ens=
uring connectivity to peers from different subnets. But even if, as you sug=
gest, a network attacker controls the target's local network, peers sti=
ll can have good security guarantees by requiring authenticated connections=
to semi-trusted peers. A client can select a set of N servers that it beli=
eves will not collude to attack it, and only sync filters if connected to a=
threshold of them. So even if the network is malicious, the attacker canno=
t forge the authenticated responses. The level of trust in these designated=
parties again is quite low because only one has to be honest. This would r=
equire something like BIP 150.<div><br></div><div>Even if clients are uncom=
fortable with whitelisting required peers, it could have a policy of requir=
ing a certain number of connections to peers that have honestly served it f=
ilters in the past. This is sort of like trust-on-first-use. This type of s=
cheme, however, would require nodes to advertise a pubkey per address, whic=
h BIP 150/151 does not support at present.</div><div><br></div><div>All in =
all, I think this is an acceptable security model for light clients. Withou=
t the ability to verify filter validity, a client would have to stop syncin=
g altogether in the presence of just one malicious peer, which is unaccepta=
ble.</div><div><br></div><div>The other concern you raise, Greg, is using a=
filter for P2P communications that we expect may be replaced in the future=
. You also raise the point that full node wallets can use the smaller filte=
rs for rescans because the filter validity is not in question. I'd perf=
ectly fine with the idea of defining two filter types in the BIP, one that =
is output script=C2=A0+ outpoint and the other output script=C2=A0+ prev sc=
ript. But I imagine some people would object to the idea of full nodes stor=
ing two different filters that overlap in contents. If we had to pick just =
one though, I'm strongly in support of output script=C2=A0+ outpoint so=
that BIP 157 can be deployed ASAP without a consensus change. It's ent=
irely possible we will learn even more about optimal filter design through =
deployment and adoption.</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Fri, Jun 1, 2018 at 5:22 PM Gregory Maxwell <<a href=3D"mail=
to:greg@xiph.org">greg@xiph.org</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">On Sat, Jun 2, 2018 at 12:01 AM, Olaoluwa Osuntokun <<a hr=
ef=3D"mailto:laolu32@gmail.com" target=3D"_blank">laolu32@gmail.com</a>>=
wrote:<br>
>> A typical network attacker (e.g.=C2=A0 someone on your lan or wifi=
segmet, or<br>
>> someone who has compromised or operates an upstream router) can be=
all of<br>
>> your peers.<br>
><br>
> This is true, but it cannot make us accept any invalid filters unless =
the<br>
> attacker is also creating invalid blocks w/ valid PoW.<br>
<br>
I wish that were the true, but absent commitments that wouldn't be the<=
br>
case unless you were always downloading all the blocks-- since you<br>
wouldn't have any sign that there was something wrong with the<br>
filter-- and downloading all the blocks would moot using the filters<br>
in the first place. :)<br>
<br>
Or have I misunderstood you massively here?<br>
<br>
For segwit originally I had proposed adding additional commitments<br>
that would make it possible to efficiently prove invalidity of a<br>
block; but that got stripped because many people were of the view that<br>
the "assume you have at least one honest peer who saw that block and<b=
r>
rejected it to tell you that the block was invalid" security<br>
assumption was of dubious value. Maybe it's more justifiable to make<br=
>
use of a dubious assumption for a P2P feature than for a consensus<br>
feature?=C2=A0 Perhaps,=C2=A0 I'd rather have both filter types from da=
y one so<br>
that things not implementing the comparison techniques don't get the<br=
>
efficiency loss or the extra work to change filter types for a<br>
consensus one.<br>
<br>
[I think now that we're much closer to a design that would be worth<br>
making a consensus committed version of than we were a few months ago<br>
now, since we are effectively already on a second generation of the<br>
design with the various improvements lately]<br>
</blockquote></div>
--000000000000fb5fe3056d9f18ba--
|
