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
|
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 2FA66D35;
Wed, 9 May 2018 23:01:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3739D67F;
Wed, 9 May 2018 23:01:51 +0000 (UTC)
Received: by mail-wm0-f45.google.com with SMTP id l1-v6so1149710wmb.2;
Wed, 09 May 2018 16:01: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=DLf+QXEn5AVs3HIJmbGiUhmFlAOHdqqn7cNrXjkfIfQ=;
b=YW+falIP8nPH9ayn5qJNIQrqkkAo8iXgmvXVBZHizOBrjgboLzlQW/3eb52U+MnoZD
GuKGFSGHBfHT4H6I0gtDOFx8vESKdRx1rZm/75TQ1ZXnttsJHMEIkKh/osYItfBSd7W+
wDb3ZRfrB31ZiDHD0WtTtNYzsuMYCwmE/+YtqaKhJKtSYV1q0esoXYNELEfOaATumPUM
coqqt5ZFnOhxHTcp8bwZXfeL1cSdluPso+W/6ifnchA7RhEf/kuXLH0yLW33SdyUNkap
tb0mLr1pGx5fSjg7zAVypjgnWhN5bXwmAn2UCy8KhoRHCFddkRMR6w4aChij3u+ibrfc
VwTA==
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=DLf+QXEn5AVs3HIJmbGiUhmFlAOHdqqn7cNrXjkfIfQ=;
b=S3mO7RiYUZ3o8EKM/LTMu06zy/iCtNjmC+15aZMG/VEjyGZzciL1OyrEuwIfqOZad9
jQCl8m4+JD5xz4XwsxRJkiHu/LndxDSSfpgveiPn1vBbgac8G+SvqKOp80N+waZ/atcn
YKHPkXbJvnuUexBwzr5rRHswnggBBIWzVovurIqdAv7h6oAnedNdUq63bavFhp2yhK6g
TAANCOig5o8ebwCAE/WY++5wTqKGPVElG615ahaSH8UXH+B1XbLX9dpUxK0sODikyw68
2DROjzwg6z7jWvW7cHL7gsIW03T63IrV8/HHoc+9OMABpWfDAnRpOjBXXQJVao8S4/95
9wqg==
X-Gm-Message-State: ALQs6tDMtD8whMdSga/Y1FcIVzdh0GZnmZsQiMDmbV2CMY6ae+FR0GjH
bpnrZZIlerHemMvxm8WST+ATg0AKi98vsqH7HSk=
X-Google-Smtp-Source: AB8JxZqrGvo2Yvq7lLD+mg5+KkJaNuheb8f0RYmf9M2vb0MdvVkR4xS9liRb6uFlEKjbnnYWdLylIyt5FLa7wx0I8AU=
X-Received: by 2002:a50:81e3:: with SMTP id
90-v6mr63549857ede.252.1525906909651;
Wed, 09 May 2018 16:01:49 -0700 (PDT)
MIME-Version: 1.0
References: <871sewirni.fsf@gmail.com> <87sh73fe4h.fsf@gmail.com>
<20180508144021.GA15921@erisian.com.au>
In-Reply-To: <20180508144021.GA15921@erisian.com.au>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Wed, 09 May 2018 23:01:39 +0000
Message-ID: <CAO3Pvs9WZ2+oNrXo6r0ic7jmZ8wbH6eA=WJt6nsUSV5c7STwBw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004f671d056bcde331"
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: lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP sighash_noinput
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, 09 May 2018 23:01:52 -0000
--0000000000004f671d056bcde331
Content-Type: text/plain; charset="UTF-8"
> The current proposal kind-of limits the potential damage by still
committing
> to the prevout amount, but it still seems a big risk for all the people
that
> reuse addresses, which seems to be just about everyone.
The typical address re-use doesn't apply here as this is a sighash flag that
would only really be used for doing various contracts on Bitcoin. I don't
see any reason why "regular" wallets would update to use this sighash flag.
We've also seen first hand with segwit that wallet authors are slow to pull
in the latest and greatest features available, even if they solve nuisance
issues like malleability and can result in lower fees.
IMO, sighash_none is an even bigger footgun that already exists in the
protocol today.
-- Laolu
On Tue, May 8, 2018 at 7:41 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev
> wrote:
> > Given the general enthusiasm, and lack of major criticism, for the
> > `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing devil's
> advocate here, but either way I think criticism always helps produce
> the best proposal, so....
>
> The big concern I have with _NOINPUT is that it has a huge failure
> case: if you use the same key for multiple inputs and sign one of them
> with _NOINPUT, you've spent all of them. The current proposal kind-of
> limits the potential damage by still committing to the prevout amount,
> but it still seems a big risk for all the people that reuse addresses,
> which seems to be just about everyone.
>
> I wonder if it wouldn't be ... I'm not sure better is the right word,
> but perhaps "more realistic" to have _NOINPUT be a flag to a signature
> for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
> so that it's fundamentally not possible to trick someone who regularly
> reuses keys to sign something for one input that accidently authorises
> spends of other inputs as well.
>
> Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE)
> wouldn't be equally effective for the forseeable usecases? That would
> ensure that a _NOINPUT signature is only ever valid for keys deliberately
> intended to be single use, rather than potentially valid for every key.
>
> It would be ~34 witness bytes worse than being able to spend a Schnorr
> aggregate key directly, I guess; but that's not worse than the normal
> taproot tradeoff: you spend the aggregate key directly in the normal,
> cooperative case; and reserve the more expensive/NOINPUT case for the
> unusual, uncooperative cases. I believe that works fine for eltoo: in
> the cooperative case you just do a SIGHASH_ALL spend of the original
> transaction, and _NOINPUT isn't needed.
>
> Maybe a different opcode maybe makes sense at a "philosophical" level:
> normal signatures are signing a spend of a particular "coin" (in the
> UTXO sense), while _NOINPUT signatures are in some sense signing a spend
> of an entire "wallet" (all the coins spendable by a particular key, or
> more accurately for the current proposal, all the coins of a particular
> value spendable by a particular key). Those are different intentions,
> so maybe it's reasonable to encode them in different addresses, which
> in turn could be done by having a new opcode for _NOINPUT.
>
> A new opcode has the theoretical advantage that it could be deployed
> into the existing segwit v0 address space, rather than waiting for segwit
> v1. Not sure that's really meaningful, though.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000004f671d056bcde331
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>> The current proposal kind-of limits the potentia=
l damage by still committing</div><div>> to the prevout amount, but it s=
till seems a big risk for all the people that</div><div>> reuse addresse=
s, which seems to be just about everyone.</div><div><br></div><div>The typi=
cal address re-use doesn't apply here as this is a sighash flag that</d=
iv><div>would only really be used for doing various contracts on Bitcoin. I=
don't</div><div>see any reason why "regular" wallets would u=
pdate to use this sighash flag.</div><div>We've also seen first hand wi=
th segwit that wallet authors are slow to pull</div><div>in the latest and =
greatest features available, even if they solve nuisance</div><div>issues l=
ike malleability and can result in lower fees.</div><div><br></div><div>IMO=
, sighash_none is an even bigger footgun that already exists in the</div><d=
iv>protocol today.</div><div><br></div><div>-- Laolu</div><div><br></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, May 8, 2018 at 7:41 A=
M Anthony Towns via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">On Mon, May 07, 2018 at 09:40:46PM +020=
0, Christian Decker via bitcoin-dev wrote:<br>
> Given the general enthusiasm, and lack of major criticism, for the<br>
> `SIGHASH_NOINPUT` proposal, [...]<br>
<br>
So first, I'm not sure if I'm actually criticising or playing devil=
's<br>
advocate here, but either way I think criticism always helps produce<br>
the best proposal, so....<br>
<br>
The big concern I have with _NOINPUT is that it has a huge failure<br>
case: if you use the same key for multiple inputs and sign one of them<br>
with _NOINPUT, you've spent all of them. The current proposal kind-of<b=
r>
limits the potential damage by still committing to the prevout amount,<br>
but it still seems a big risk for all the people that reuse addresses,<br>
which seems to be just about everyone.<br>
<br>
I wonder if it wouldn't be ... I'm not sure better is the right wor=
d,<br>
but perhaps "more realistic" to have _NOINPUT be a flag to a sign=
ature<br>
for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode inste=
ad,<br>
so that it's fundamentally not possible to trick someone who regularly<=
br>
reuses keys to sign something for one input that accidently authorises<br>
spends of other inputs as well.<br>
<br>
Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE)<br>
wouldn't be equally effective for the forseeable usecases? That would<b=
r>
ensure that a _NOINPUT signature is only ever valid for keys deliberately<b=
r>
intended to be single use, rather than potentially valid for every key.<br>
<br>
It would be ~34 witness bytes worse than being able to spend a Schnorr<br>
aggregate key directly, I guess; but that's not worse than the normal<b=
r>
taproot tradeoff: you spend the aggregate key directly in the normal,<br>
cooperative case; and reserve the more expensive/NOINPUT case for the<br>
unusual, uncooperative cases. I believe that works fine for eltoo: in<br>
the cooperative case you just do a SIGHASH_ALL spend of the original<br>
transaction, and _NOINPUT isn't needed.<br>
<br>
Maybe a different opcode maybe makes sense at a "philosophical" l=
evel:<br>
normal signatures are signing a spend of a particular "coin" (in =
the<br>
UTXO sense), while _NOINPUT signatures are in some sense signing a spend<br=
>
of an entire "wallet" (all the coins spendable by a particular ke=
y, or<br>
more accurately for the current proposal, all the coins of a particular<br>
value spendable by a particular key). Those are different intentions,<br>
so maybe it's reasonable to encode them in different addresses, which<b=
r>
in turn could be done by having a new opcode for _NOINPUT.<br>
<br>
A new opcode has the theoretical advantage that it could be deployed<br>
into the existing segwit v0 address space, rather than waiting for segwit<b=
r>
v1. Not sure that's really meaningful, though.<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<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></div>
--0000000000004f671d056bcde331--
|
