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
|
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 8BBAEA4DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Feb 2019 00:06:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com
[209.85.219.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A5E005D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 6 Feb 2019 00:06:12 +0000 (UTC)
Received: by mail-yb1-f179.google.com with SMTP id k9so1798712ybg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 05 Feb 2019 16:06:12 -0800 (PST)
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=dshSWAtVxdcR1FHPv7r2V0Im41zbUcuTC6THHlz+74E=;
b=ZnI9V9eQfQywcQirPhGP9c28iGduKKrVqc2vYidjbCJyOAy1VZLn9p5mFLU5KyYngo
Hl7Ynf9NGpYR+OAYGLgmNvioO+U+r7OejB9VuZjIOl2zhuMgcweV/TMR/+vyWspfnpsM
CO/d7C9jUMeN+63ITkyDA4FVPQinXMhVTgHSEte0FuKW/kawkIe5wpSSSortsdFG1EZ2
WvPCBwCYHQFxSMymUKi4rZnZXQ2GJFrQMeKvuvLKwMeAkZ7IuHpPtoPjATCHFdyNzMs/
R6zApFvijZkvaA+I8RLV72hnErtWYKPUo87C0mWHt6PKL6PDg0wBm99t/jW2cTH8q3Gb
Fuqg==
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=dshSWAtVxdcR1FHPv7r2V0Im41zbUcuTC6THHlz+74E=;
b=hdPbK1JxqjX4j4buqog+pJn0yquH4jWcukSLmykAozKOr6ssG0pjA1B/Jsj5or0a2r
9PZAp5Pcq3Ebup+8gvZFZBL+lACnXj4/F7r+e4CmsBM6JQP7OaOihA1KsdVbb66fMaso
Vf7ofmgxfnM9NfN2tBrUqOhAkDJPZPV3sbevftBumktOKUBx2NB3RWcJp1yb/oE6t43g
qC0lrT/mK50bRtaBcQqQG8B3itJw02ETyf4+LS8ytCDMajwFgmvaLW89ceETZmViOeia
e8c/iMezGgiXyJQROrTxFI1QTkPmmYAzNESxVWtcYjOC54gQEGStTiI/iQvWxEXea2Rf
kkrQ==
X-Gm-Message-State: AHQUAuaDAjH0EqVOJSLUJJGVbGDBRQPKWtVW1zNaSHMRoZD8zJVAMqXm
lEekr6NsoVpFBN29CNlE1bYbUN7kjKt41NwmySs=
X-Google-Smtp-Source: AHgI3IYNSOlGOp/wM3TApR1mCcumyqWMYt9ge54+PH3SAhNswHi7rtLjWgKI8OxNXFjhoA9v99vMID2+xY24SekdW+0=
X-Received: by 2002:a25:241:: with SMTP id 62mr6042862ybc.201.1549411571428;
Tue, 05 Feb 2019 16:06:11 -0800 (PST)
MIME-Version: 1.0
References: <6D57649F-0236-4FBA-8376-4815F5F39E8A@gmail.com>
<CADZtCSgKu1LvjePNPT=0C0UYQvb47Ca0YN+B_AfgVNTpcOno4w@mail.gmail.com>
<CDAFC2F7-A0AD-460B-B5B1-A717F7EC700E@gmail.com>
<CAO3Pvs_gvYy99Bch=7RwVszM_0PFTKUyqDVok=xfm4OOcqwaaQ@mail.gmail.com>
<97c96822-df5e-0c65-3992-6e292577ce66@mattcorallo.com>
In-Reply-To: <97c96822-df5e-0c65-3992-6e292577ce66@mattcorallo.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Tue, 5 Feb 2019 16:05:57 -0800
Message-ID: <CAO3Pvs8wKgxo_z73FNy6Dgo_Z68Pa13CU7xHzUbpNATraqACpA@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="00000000000053729505812e7e3d"
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
X-Mailman-Approved-At: Wed, 06 Feb 2019 15:48:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Jim Posen <jimpo@coinbase.com>
Subject: Re: [bitcoin-dev] Interrogating a BIP157 server,
BIP158 change proposal
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: Wed, 06 Feb 2019 00:06:13 -0000
--00000000000053729505812e7e3d
Content-Type: text/plain; charset="UTF-8"
Hi Matt,
> In (the realistic) thread model where an attacker is trying to blind you
> from some output, they can simply give you "undo data" where scriptPubKeys
> are OP_TRUE instead of the real script and you'd be none the wiser.
It depends on the input. If I'm trying to verify an input that's P2WSH,
since the witness script is included in the witness (the last element), I
can easily verify that the pkScript given is the proper witness program.
> Huh? I don't think we should seriously consider
> only-one-codebase-has-deployed-anything-with-very-limited-in-the-wild-use
as
> "too late into the current deployment"?
I'd wager that most developers reading this email right now are familiar
with neutrino as a project. Many even routinely use "neutrino" to refer to
BIP 157+158. There are several projects in the wild that have already
deployed applications built on lnd+neutrino live on mainnet. lnd+neutrino is
also the only project (as far as I'm aware) that has fully integrated the
p2p BIP 157+158 into a wallet, and also uses the filters for higher level
applications.
I'm no stranger to this argument, as I made the exact same one 7 months ago
when the change was originally discussed. Since then I realized that using
input scripts can be even _more_ flexible as light clients can use them as
set up or triggers for multi-party protocols such as atomic swaps. Using
scripts also allows for faster rescans if one knows all their keys ahead of
time, as the checks can be parallelized. Additionally, the current filter
also lends better to an eventual commitment as you literally can't remove
anything from it, and still have it be useful for the traditional wallet use
case.
As I mentioned in my last email, this can be added as an additional filter
type, leaving it up the full node implementations that have deployed the
base protocol to integrate it or not.
-- Laolu
On Tue, Feb 5, 2019 at 4:21 AM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
>
> On 2/4/19 8:18 PM, Jim Posen via bitcoin-dev wrote:
> - snip -
> > 1) Introduce a new P2P message to retrieve all prev-outputs for a given
> > block (essentially the undo data in Core), and verify the scripts
> > against the block by executing them. While this permits some forms of
> > input script malleability (and thus cannot discriminate between all
> > valid and invalid filters), it restricts what an attacker can do. This
> > was proposed by Laolu AFAIK, and I believe this is how btcd is
> proceeding.
>
> I'm somewhat confused by this - how does the undo data help you without
> seeing the full (mistate compressed) transaction? In (the realistic)
> thread model where an attacker is trying to blind you from some output,
> they can simply give you "undo data" where scriptPubKeys are OP_TRUE
> instead of the real script and you'd be none the wiser.
>
> On 2/5/19 1:42 AM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> - snip -
> > I think it's too late into the current deployment of the BIPs to change
> > things around yet again. Instead, the BIP already has measures in place
> for
> > adding _new_ filter types in the future. This along with a few other
> filter
> > types may be worthwhile additions as new filter types.
> - snip -
>
> Huh? I don't think we should seriously consider
> only-one-codebase-has-deployed-anything-with-very-limited-in-the-wild-use
> as "too late into the current deployment"?
>
> Matt
>
--00000000000053729505812e7e3d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Matt,</div><div><br></div><div>> In (the realis=
tic) thread model where an attacker is trying to blind you</div><div>> f=
rom some output, they can simply give you "undo data" where scrip=
tPubKeys</div><div>> are OP_TRUE instead of the real script and you'=
d be none the wiser.</div><div><br></div><div>It depends on the input. If I=
'm trying to verify an input that's P2WSH,</div><div>since the witn=
ess script is included in the witness (the last element), I</div><div>can e=
asily verify that the pkScript given is the proper witness program.</div><d=
iv><br></div><div>> Huh? I don't think we should seriously consider<=
/div><div>> only-one-codebase-has-deployed-anything-with-very-limited-in=
-the-wild-use as</div><div>> "too late into the current deployment&=
quot;?</div><div><br></div><div>I'd wager that most developers reading =
this email right now are familiar</div><div>with neutrino as a project. Man=
y even routinely use "neutrino" to refer to</div><div>BIP 157+158=
. There are several projects in the wild that have already</div><div>deploy=
ed applications built on lnd+neutrino live on mainnet. lnd+neutrino is</div=
><div>also the only project (as far as I'm aware) that has fully integr=
ated the</div><div>p2p BIP 157+158 into a wallet, and also uses the filters=
for higher level</div><div>applications.</div><div><br></div><div>I'm =
no stranger to this argument, as I made the exact same one 7 months ago</di=
v><div>when the change was originally discussed. Since then I realized that=
using</div><div>input scripts can be even _more_ flexible as light clients=
can use them as</div><div>set up or triggers for multi-party protocols suc=
h as atomic swaps. Using</div><div>scripts also allows for faster rescans i=
f one knows all their keys ahead of</div><div>time, as the checks can be pa=
rallelized. Additionally, the current filter</div><div>also lends better to=
an eventual commitment as you literally can't remove</div><div>anythin=
g from it, and still have it be useful for the traditional wallet use</div>=
<div>case.</div><div><br></div><div>As I mentioned in my last email, this c=
an be added as an additional filter</div><div>type, leaving it up the full =
node implementations that have deployed the</div><div>base protocol to inte=
grate it or not.</div><div><br></div><div>-- Laolu</div><div><br></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Fe=
b 5, 2019 at 4:21 AM Matt Corallo <<a href=3D"mailto:lf-lists@mattcorall=
o.com">lf-lists@mattcorallo.com</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"><br>
On 2/4/19 8:18 PM, Jim Posen via bitcoin-dev wrote:<br>
- snip -<br>
=C2=A0> 1) Introduce a new P2P message to retrieve all prev-outputs for =
a given<br>
=C2=A0> block (essentially the undo data in Core), and verify the script=
s<br>
=C2=A0> against the block by executing them. While this permits some for=
ms of<br>
=C2=A0> input script malleability (and thus cannot discriminate between =
all<br>
=C2=A0> valid and invalid filters), it restricts what an attacker can do=
. This<br>
=C2=A0> was proposed by Laolu AFAIK, and I believe this is how btcd is <=
br>
proceeding.<br>
<br>
I'm somewhat confused by this - how does the undo data help you without=
<br>
seeing the full (mistate compressed) transaction? In (the realistic) <br>
thread model where an attacker is trying to blind you from some output, <br=
>
they can simply give you "undo data" where scriptPubKeys are OP_T=
RUE <br>
instead of the real script and you'd be none the wiser.<br>
<br>
On 2/5/19 1:42 AM, Olaoluwa Osuntokun via bitcoin-dev wrote:<br>
- snip -<br>
> I think it's too late into the current deployment of the BIPs to c=
hange<br>
> things around yet again. Instead, the BIP already has measures in plac=
e for<br>
> adding _new_ filter types in the future. This along with a few other f=
ilter<br>
> types may be worthwhile additions as new filter types.<br>
- snip -<br>
<br>
Huh? I don't think we should seriously consider <br>
only-one-codebase-has-deployed-anything-with-very-limited-in-the-wild-use <=
br>
as "too late into the current deployment"?<br>
<br>
Matt<br>
</blockquote></div></div>
--00000000000053729505812e7e3d--
|
