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
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
|
Return-Path: <jlrubin@mit.edu>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 565BFC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 04:35:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 4844488ED5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 04:35:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id zzBZBlO2zYbE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 04:35:13 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by hemlock.osuosl.org (Postfix) with ESMTPS id F1BD288BC3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 May 2020 04:35:12 +0000 (UTC)
Received: from mail-il1-f171.google.com (mail-il1-f171.google.com
[209.85.166.171]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0424Z9x2018027
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 2 May 2020 00:35:10 -0400
Received: by mail-il1-f171.google.com with SMTP id m5so6234142ilj.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 01 May 2020 21:35:10 -0700 (PDT)
X-Gm-Message-State: AGi0PuZir9nQ2eVwhFH7fOYDw+jk79DHN0dzlWFQPFkUvajFZa9+tdiR
JUtYsSoGarOILHMjldehDMJlZEKF+ecnWFRHxZA=
X-Google-Smtp-Source: APiQypLmSFNWVUDY9JI3K7XfQkuEqMmVOuIzK4aTdOkJZM046uiROG9Oz59px9MQgsq1zSSgqIN4jHSZv6/zLBACj/U=
X-Received: by 2002:a92:8c90:: with SMTP id s16mr6865681ill.164.1588394109774;
Fri, 01 May 2020 21:35:09 -0700 (PDT)
MIME-Version: 1.0
References: <CACvH2e=3s2kZWnytMySTv8U4pny3i0rEWas7NxzLxf5J7BewTg@mail.gmail.com>
<CAMZUoKm9sogtKS0YqOz8JNNbiiwBdkPbdEvf67yzcJr1BZ7_wA@mail.gmail.com>
<CAB3F3Dt-HT8vX-eENE5B5Oz9Z6+he6FZWwNCq3MNExg0KA7zNw@mail.gmail.com>
In-Reply-To: <CAB3F3Dt-HT8vX-eENE5B5Oz9Z6+he6FZWwNCq3MNExg0KA7zNw@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 1 May 2020 21:35:41 -0700
X-Gmail-Original-Message-ID: <CAD5xwhi1KY8uPRMjibwboMpXmwbLR_Rfsc9JmPFjHO7ajQjX7A@mail.gmail.com>
Message-ID: <CAD5xwhi1KY8uPRMjibwboMpXmwbLR_Rfsc9JmPFjHO7ajQjX7A@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ad37a505a4a2d217"
Cc: jonasd.nick@gmail.com, Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the
signature message
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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 May 2020 04:35:15 -0000
--000000000000ad37a505a4a2d217
Content-Type: text/plain; charset="UTF-8"
At the end of the day I don't really care that much I just prefer something
that doesn't throw taproot in for another review cycle.
A side effect of this proposal is it would seem to make it not possible to
produce a signature for a transaction without having access to the inputs.
This is limiting for a number of cases where you don't care about that
data. There are a litany of use cases where you don't want to have
SIGHASH_ALL behavior, and having to sign the scriptpubkeys breaks that. So
at the very least it should respect other flags.
I also don't really understand the exact attack. So you submit a
transaction to the wallet asking them to sign input 10. They sign. They've
committed to the signature being bound to the specific COutpoint and input
index, so I don't see how they wouldn't be required to sign a second
signature with the other output too? Is there an attack you can describe
end-to-end relying on this behavior?
If you look at the TXID hash the vouts are one of the last fields
serialized. this makes it possible (at least, I think) to do a midstate
proof so that all you are providing is the hash midstate, and the relevant
transaction output, the siblings after, and the locktime. So you get to
skip all the input data, the witness data, and most of the output data.
This sort of data can easily go into the proprietary use (maybe becoming
well defined if there's a standardization push) area in PSBT, so that
hardware devices can get easy access to it. All they have to do to verify
is to finalize the hash against that buffer and match to the correct input.
As an alternative proposal, I think you can just make a separate BIP for
some new sigash flags that can be reviewed separately from taproot. There's
a lot of value in investing in figuring out more granular controls over
what the signature hash is you sign, which may have some exciting
contracting implications!
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Fri, May 1, 2020 at 5:26 AM Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> For what it's worth this measure had been discussed as a lightweight way
> of informing offline signers if inputs were segwit or not for malleability
> analysis reasons. So there's at least a couple direct use-cases it seems.
>
> On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> While I'm not entirely convinced yet that accertaining non-ownership of
>> an input is a robust method of solving the problem here, I also see little
>> reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is
>> already indirectly covered through the outpoints, so it is just a matter of
>> optimization. Furthermore in the consensus code, the ScriptPubKeys are
>> part of the UTXO data set, and it is already being retrieved as part of the
>> transaction checking process, so it is readily available.
>>
>> I'm not sure how much my opinion on the topic matters, but I did include
>> this kind of functionality in my design for Simplicity on Elements, and I
>> have been leaning towards adding this kind of functionality in my Bitcoin
>> demo application of Simplicity.
>>
>> Regarding specifics, I personally think it would be better to keep the
>> hashes of the ScriptPubKeys separate from the hashes of the input values.
>> This way anyone only interested in input values does not need to wade
>> through what are, in principle, arbitrarily long ScriptPubKeys in order to
>> check the input values (which each fixed size). To that end, I would also
>> (and independently) propose separating the hashing of the output values
>> from the output ScriptPubKeys in `sha_outputs` so again, applications
>> interested only in summing the values of the outputs (for instance to
>> compute fees) do not have to wade through those arbitrarily long
>> ScriptPubKeys in the outputs.
>>
>> On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi everyone,
>>>
>>> In the current draft of BIP-0341 [1] the signature message commits to
>>> the scriptPubKey of the output being spent by the input. I propose that the
>>> signature message should commit to the scriptPubKeys of *all* transaction
>>> inputs.
>>>
>>> In certain applications like CoinJoin, a wallet has to deal with
>>> transactions containing external inputs. To calculate the actual amount
>>> that the user is spending, the wallet needs to reliably determine for each
>>> input whether it belongs to the wallet or not. Without such a mechanism an
>>> adversary can fool the wallet into displaying incorrect information about
>>> the amount being spent, which can result in theft of user funds [2].
>>>
>>> In order to ascertain non-ownership of an input which is claimed to be
>>> external, the wallet needs the scriptPubKey of the previous output spent by
>>> this input. It must acquire the full transaction being spent and verify its
>>> hash against that which is given in the outpoint. This is an obstacle in
>>> the implementation of lightweight air-gapped wallets and hardware wallets
>>> in general. If the signature message would commit to the scriptPubKeys of
>>> all transaction inputs, then the wallet would only need to acquire the
>>> scriptPubKey of the output being spent without having to acquire and verify
>>> the hash of the entire previous transaction. If an attacker would provide
>>> an incorrect scriptPubKey, then that would cause the wallet to generate an
>>> invalid signature message.
>>>
>>> Note that committing only to the scriptPubKey of the output being spent
>>> is insufficient for this application, because the scriptPubKeys which are
>>> needed to ascertain non-ownership of external inputs are precisely the ones
>>> that would not be included in any of the signature messages produced by the
>>> wallet.
>>>
>>> The obvious way to implement this is to add another hash to the
>>> signature message:
>>> sha_scriptPubKeys (32): the SHA256 of the serialization of all
>>> scriptPubKeys of the previous outputs spent by this transaction.
>>>
>>> Cheers,
>>> Andrew Kozlik
>>>
>>> [1]
>>> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
>>> [2]
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000ad37a505a4a2d217
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">At the end of the day I d=
on't really care that much I just prefer something that doesn't thr=
ow taproot in for another review cycle.</div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000">A side effect of this proposa=
l is it would seem to make it not possible to produce a signature for a tra=
nsaction without having access to the inputs. This is limiting for a number=
of cases where you don't care about that data. There are a litany of u=
se cases where you don't want to have SIGHASH_ALL behavior, and having =
to sign the scriptpubkeys breaks that. So at the very least it should respe=
ct other flags.</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">I also don't really understand the exact attack.=
So you submit a transaction to the wallet asking them to sign input 10. Th=
ey sign. They've committed to the signature being bound to the specific=
COutpoint and input index, so I don't see how they wouldn't be req=
uired to sign a second signature with the other output too? Is there an att=
ack you can describe end-to-end relying on this behavior?<br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">If you =
look at the TXID hash the vouts are one of the last fields serialized. this=
makes it possible (at least, I think) to do a midstate proof so that all y=
ou are providing is the hash midstate, and the relevant transaction output,=
=C2=A0 the siblings after, and the locktime. So you get to skip all the in=
put data, the witness data, and most of the output data.<br></div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">This sor=
t of data can easily go into the proprietary use (maybe becoming well defin=
ed if there's a standardization push) area in PSBT, so that hardware de=
vices can get easy access to it. All they have to do to verify is to finali=
ze the hash against that buffer and match to the correct input.</div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000">As an alternative proposal, I think y=
ou can just make a separate BIP for some new sigash flags that can be revie=
wed separately from taproot. There's a lot of value in investing in fig=
uring out more granular controls over what the signature hash is you sign, =
which may have some exciting contracting implications!<br clear=3D"all"></d=
iv><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_=
signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubi=
n" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyR=
ubin" target=3D"_blank"></a></div></div></div><br></div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 1, 2020 at 5:=
26 AM Greg Sanders via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto"=
>For what=C2=A0it's worth this measure had been discussed as a lightwei=
ght way of informing offline signers if inputs were segwit or not for malle=
ability analysis reasons. So there's at least a couple direct use-cases=
it seems.=C2=A0</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitco=
in-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Whil=
e I'm not entirely convinced yet that accertaining non-ownership of an =
input is a robust method of solving the problem here, I also see little rea=
son not to amend BIP-341 as proposed. The ScriptPubKeys in question is alre=
ady indirectly covered through the outpoints, so it is just a matter of opt=
imization.=C2=A0 Furthermore in the consensus code, the ScriptPubKeys are =
part of the UTXO data set, and it is already being retrieved as part of the=
transaction checking process, so it is readily available.</div><div><br></=
div><div>I'm not sure how much my opinion on the topic matters, but I d=
id include this kind of functionality in my design for Simplicity on Elemen=
ts, and I have been leaning towards adding this kind of functionality in my=
Bitcoin demo application of Simplicity.</div><div><br></div><div>Regarding=
specifics, I personally think it would be better to keep the hashes of the=
ScriptPubKeys separate from the hashes of the input values.=C2=A0 This way=
anyone only interested in input values does not need to wade through what =
are, in principle, arbitrarily long ScriptPubKeys in order to check the inp=
ut values (which each fixed size).=C2=A0 To that end, I would also (and ind=
ependently) propose separating the hashing of the output values from the ou=
tput ScriptPubKeys in `sha_outputs` so again, applications interested only =
in summing the values of the outputs (for instance to compute fees) do not =
have to wade through those arbitrarily long ScriptPubKeys in the outputs.<b=
r></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi everyo=
ne,<br><br>In the current draft of BIP-0341 [1] the signature message commi=
ts to the scriptPubKey of the output being spent by the input. I propose th=
at the signature message should commit to the scriptPubKeys of *all* transa=
ction inputs.<br><br>In certain applications like CoinJoin, a wallet has to=
deal with transactions containing external inputs. To calculate the actual=
amount that the user is spending, the wallet needs to reliably determine f=
or each input whether it belongs to the wallet or not. Without such a mecha=
nism an adversary can fool the wallet into displaying incorrect information=
about the amount being spent, which can result in theft of user funds [2].=
<br><br>In order to ascertain non-ownership of an input which is claimed to=
be external, the wallet needs the scriptPubKey of the previous output spen=
t by this input. It must acquire the full transaction being spent and verif=
y its hash against that which is given in the outpoint. This is an obstacle=
in the implementation of lightweight air-gapped wallets and hardware walle=
ts in general. If the signature message would commit to the scriptPubKeys o=
f all transaction inputs, then the wallet would only need to acquire the sc=
riptPubKey of the output being spent without having to acquire and verify t=
he hash of the entire previous transaction. If an attacker would provide an=
incorrect scriptPubKey, then that would cause the wallet to generate an in=
valid signature message.<br><div><br></div><div>Note that committing only t=
o the scriptPubKey of the output being spent is insufficient for this appli=
cation, because the scriptPubKeys which are needed to ascertain non-ownersh=
ip of external inputs are precisely the ones that would not be included in =
any of the signature messages produced by the wallet.</div><div><br></div>T=
he obvious way to implement this is to add another hash to the signature me=
ssage:<br>sha_scriptPubKeys (32): the SHA256 of the serialization of all sc=
riptPubKeys of the previous outputs spent by this transaction.<br><div><br>=
</div><div>Cheers,<br></div><div>Andrew Kozlik</div><div><br></div>[1] <a h=
ref=3D"https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#commo=
n-signature-message" rel=3D"noreferrer" target=3D"_blank">https://github.co=
m/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message</a><=
br>[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
017-August/014843.html" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html</a><br></=
div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000ad37a505a4a2d217--
|