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
|
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 0F0721334
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Jun 2018 00:01:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 592F4108
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Jun 2018 00:01:56 +0000 (UTC)
Received: by mail-wm0-f68.google.com with SMTP id q4-v6so8113731wmq.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 01 Jun 2018 17:01:56 -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=GpgjU9ZF4uHnwdyU9Yib6iW/X8ZEsi6Hm62egx7BBuU=;
b=qEfm7W1+IZZy0BZcDsf84xm/iPHSJx9+OvgT0qePzGZ16zJQem6l+tHVR9yIt+AxZa
DdDNySIAa3L+7mN/Wp8jGf/WVNsTMGPKUAC8LLVztvGjhxFInLAPMC3gLmtrQs5cAoaf
elcjG+o0Oy+8FYIfSSqh4juypp7KRaIyToZ7fVeFV1oWGQ8W3b5/8r1iYZVjjNX0Z6zi
7K+mIXTkacM+0GR8Z/4mQLr4/Uj6NU6F1gkAaEPqtuiSkqcn02dH5F4VNCGfcNl5hD+g
IUAUw8HSJR7qS+EO5ksfhEzJGJUMdQRvJveOyFdDgZh+24Bo5hXcC8MCtPMI1omUjPSN
7rrw==
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=GpgjU9ZF4uHnwdyU9Yib6iW/X8ZEsi6Hm62egx7BBuU=;
b=aWRBQ9hfRl3inZIHrJkclZQjU28+ySSaqea+M41lSEdcIMzr4kPrYnG2RhVSkZI+Lk
xLETzP8X4/YtLLsHMi/ARbfjl8Rt1JcLwksvEX7J9F3FVkBQrPgCbcTTcNDLoMAlxk9i
/u6Wo+OK4PpTsIo4f3ZfTyyQt7TFK5eAxztJpMm7xL2uNFuzTOGsVIqyfsScCjWRdRAm
OSvcS7eXF2hXO1jIaZtRywPSlkUy21ozUQze7YrRDRu8rqXW4JwtyZG1+a0Ntyhu4E54
whZiTEmUbxJ+eV6QJMbbaUZcCS55VSf54+NfJ5a/tlOVQEd4hztTP2Eacz0mlx8sv8yG
cXzA==
X-Gm-Message-State: ALKqPwdspe+VGm1MBldVVSWTiI3wdHUF+QFIRQhP3WPD0aO/MtpHFVHz
atcRVbZTFlYX5lCBDFKeluByP00txcW0rSQaCW4=
X-Google-Smtp-Source: ADUXVKIXfL0OfkqdSqSRaxKJtLRcg6vJbwOBRUfaPh78xi7vZhvLYmxgu/7umP+7ki4EsOC/7rXJgYzRk+VgH6+TSt8=
X-Received: by 2002:a50:a3b8:: with SMTP id
s53-v6mr14544324edb.271.1527897714817;
Fri, 01 Jun 2018 17:01:54 -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>
In-Reply-To: <CAAS2fgSyVi0d_ixp-auRPPzPfFeffN=hsWhWT5=EzDO3O+Ue1g@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Fri, 1 Jun 2018 17:01:43 -0700
Message-ID: <CAO3Pvs_0qCZbRCfL8EJw6gzWjZeXWcJrtg27g_SJ7+PkYTHg6A@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008b8043056d9d68cc"
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
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 00:01:57 -0000
--0000000000008b8043056d9d68cc
Content-Type: text/plain; charset="UTF-8"
> 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.
> The original propsal for using these kinds of maps was that their digests
> could eventually be commited and then checked against the commitment,
> matching the same general security model used otherwise in SPV.
Indeed, but no such proposal for committing the filters has emerged yet.
Slinging filters with new p2p messages requires much less coordination that
adding a new committed structure to Bitcoin. One could imagine that if
consensus exists to add new committed structures, then there may also be
initiatives to start to commit sig-ops, block weight, utxo's etc. As a
result one could imagine a much longer deployment cycle compared to a pure
p2p roll out in the near term, and many applications are looking for a
viable alternative to BIP 37.
> Unfortunately, using the scripts instead of the outpoints takes us further
> away from a design that is optimized for committing (or, for that matter,
> use purely locally by a wallet)...
I agree that using the prev input scripts would indeed be optimal from a
size perspective when the filters are to be committed. The current proposal
makes way for future filter types and it's likely the case that only the
most optimal filters should be committed (while other more niche filters
perhaps, remain only on the p2p level).
-- Laolu
On Thu, May 31, 2018 at 9:14 PM Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osuntokun via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > One notable thing that I left off is the proposed change to use the
> previous
> > output script rather than the outpoint. Modifying the filters in this
> > fashion would be a downgrade in the security model for light clients, as
> it
>
> Only if you make a very strong assumption about the integrity of the
> nodes the client is talkign to. 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.
>
> The original propsal for using these kinds of maps was that their
> digests could eventually be commited and then checked against the
> commitment, matching the same general security model used otherwise in
> SPV.
>
> Unfortunately, using the scripts instead of the outpoints takes us
> further away from a design that is optimized for committing (or, for
> that matter, use purely locally by a wallet)...
>
--0000000000008b8043056d9d68cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>> A typical network attacker (e.g.=C2=A0 someone o=
n your lan or wifi segmet, or</div><div>> someone who has compromised or=
operates an upstream router) can be all of</div><div>> your peers.</div=
><div><br></div><div>This is true, but it cannot make us accept any invalid=
filters unless the</div><div>attacker is also creating invalid blocks w/ v=
alid PoW.</div><div><br></div><div>> The original propsal for using thes=
e kinds of maps was that their digests</div><div>> could eventually be c=
ommited and then checked against the commitment,</div><div>> matching th=
e same general security model used otherwise in SPV.</div><div><br></div><d=
iv>Indeed, but no such proposal for committing the filters has emerged yet.=
</div><div>Slinging filters with new p2p messages requires much less coordi=
nation that</div><div>adding a new committed structure to Bitcoin. One coul=
d imagine that if</div><div>consensus exists to add new committed structure=
s, then there may also be</div><div>initiatives to start to commit sig-ops,=
block weight, utxo's etc. As a</div><div>result one could imagine a mu=
ch longer deployment cycle compared to a pure</div><div>p2p roll out in the=
near term, and many applications are looking for a</div><div>viable altern=
ative to BIP 37.</div><div><br></div><div>> Unfortunately, using the scr=
ipts instead of the outpoints takes us further</div><div>> away from a d=
esign that is optimized for committing (or, for that matter,</div><div>>=
use purely locally by a wallet)...</div><div><br></div><div>I agree that u=
sing the prev input scripts would indeed be optimal from a</div><div>size p=
erspective when the filters are to be committed. The current proposal</div>=
<div>makes way for future filter types and it's likely the case that on=
ly the</div><div>most optimal filters should be committed (while other more=
niche filters</div><div>perhaps, remain only on the p2p level).</div><div>=
<br></div><div>-- Laolu</div><div><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr">On Thu, May 31, 2018 at 9:14 PM Gregory Maxwell <<a hre=
f=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>> wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Fri, Jun 1, 2018 at 2:52 AM, Olaoluwa Osu=
ntokun via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> One notable thing that I left off is the proposed change to use the pr=
evious<br>
> output script rather than the outpoint. Modifying the filters in this<=
br>
> fashion would be a downgrade in the security model for light clients, =
as it<br>
<br>
Only if you make a very strong assumption about the integrity of the<br>
nodes the client is talkign to. A typical network attacker (e.g.<br>
someone on your lan or wifi segmet, or someone who has compromised or<br>
operates an upstream router) can be all of your peers.<br>
<br>
The original propsal for using these kinds of maps was that their<br>
digests could eventually be commited and then checked against the<br>
commitment, matching the same general security model used otherwise in<br>
SPV.<br>
<br>
Unfortunately, using the scripts instead of the outpoints takes us<br>
further away from a design that is optimized for committing (or, for<br>
that matter, use purely locally by a wallet)...<br>
</blockquote></div></div>
--0000000000008b8043056d9d68cc--
|
