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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DD61CCAA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Dec 2018 19:08:47 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A04647DB
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 Dec 2018 19:08:46 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545073713; cv=none; d=zoho.com; s=zohoarc;
b=IoQgA4zTII11nfGTrumm+je97KxzzgfEVJxJcLx0h0YSYri+2RkkutHRjPxd4IxpRt5Vzy+rhTK4xLICBrs+d3BERcvDDgm4QoTTQXbb1V9erBuw/YSwUlpttbBlR0DpCSau+iO03jUXLzSb/CJEgyAmc8iJO6f20BYzaBXKR/s=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1545073713;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=NeTy6BWtqLV9hQ1LZa/kDGRqlA2annd/PE6Hg7SZ0Iw=;
b=nbp5sdXOGLr3xl4I692tjfJeTVXHZW2qV/s7X2rQNGqPQcVqhCLgWQfHaKjpWTbkg5vzBoF2REd+R5CJcW48T9an1gWcG4IfmXBkZuo/oLPt0Tnn6ZeR583HXMJvbQGNKvqHlJ22qdP7Eb17GQ68DVb8sicPuPGG4n0w3/qJ0/k=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk;
spf=pass smtp.mailfrom=jl2012@xbt.hk;
dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118])
by mx.zohomail.com with SMTPS id 1545073711035550.7491078070161;
Mon, 17 Dec 2018 11:08:31 -0800 (PST)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <8736qyhsej.fsf@rustcorp.com.au>
Date: Tue, 18 Dec 2018 03:08:26 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6DE5291C-629D-4080-9B0C-E18BEFA28B16@xbt.hk>
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
<87ftv3xerx.fsf@rustcorp.com.au>
<DAAB7568-A004-4897-B5B3-0FBBC6895246@xbt.hk>
<87pnu6s3v5.fsf@rustcorp.com.au> <87h8fiqn1z.fsf@rustcorp.com.au>
<20181214093002.p2nvfrlaycqblww3@erisian.com.au>
<8736qyhsej.fsf@rustcorp.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3445.100.39)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Tue, 18 Dec 2018 02:17:16 +0000
Subject: Re: [bitcoin-dev] Safer sighashes and more granular 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: Mon, 17 Dec 2018 19:08:48 -0000
> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> =
writes:
>> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via =
bitcoin-dev wrote:
>>> And is it worthwhile doing the mask complexity, rather than just
>>> removing the commitment to script with NOINPUT? It *feels* safer to
>>> restrict what scripts we can sign, but is it?
>>=20
>> If it's not safer in practice, we've spent a little extra complexity
>> committing to a subset of the script in each signature to no gain. If
>> it is safer in practice, we've prevented people from losing funds. =
I'm
>> all for less complexity, but not for that tradeoff.
>=20
> There are many complexities we could add, each of which would prevent
> loss of funds in some theoretical case.
Every security measures are overkill, until someone get burnt. If these =
security measures are really effective, no one will get burnt. The =
inevitable conclusion is: every effective security measures are =
overkill.
>=20
> =46rom practical experience; reuse of private keys between lightning =
and
> other things is not how people will lose funds[1].
Assuming an user holds a private key exclusively and securely, currently =
there are only 2 ways to lose funds by private key reuse: 1. reusing the =
same signature nonce; 2. signing the hash =E2=80=9Cone=E2=80=9D, for the =
SIGHASH_SINGLE consensus bug.
People lost money for the first reason. Since this is a feature of the =
signature schemes we use, unavoidably that will happen again from time =
to time. The second one has been fixed in segwit (though incompletely), =
and could be completely fixed with a simple softfork.
Overall speaking, while private key reuse hurts fungibility and privacy, =
it is not terribly insecure, as long as you use rfc6979 and are not =
foolish enough to sign hash =E2=80=9Cone=E2=80=9D. This actually thanks =
to the fact that signatures always committed to the previous txid. It =
makes sure that a signature is never valid for more than one UTXO. =
Unfortunately, the guarantee of non-replayability incentified the =
practice of key-reuse, since the day-one of bitcoin. While NOINPUT =
fundamentally changes this security assumption, it won=E2=80=99t change =
this long-established culture of key reuse.
So you argument seems just begging the question. Without NOINPUT, it is =
just impossible to lose money by key reuse, and this is exactly the =
topic we are debating.
>=20
> It *is* however non-trivially more complicated for wallets; they
> currently have a set of script templates which they will sign (ie. no
> OP_CODESEPARATOR) and I implemented BIP 143 with only the simplest of
> naive code[2]. In particular, there is no code to parse scripts.
Sorry that I=E2=80=99m not familiar with the implementation details of =
your wallet. But as you don=E2=80=99t have code to parse scripts, I =
assume your wallet can=E2=80=99t handle OP_CODESEPARATOR? However, this =
is exactly what you should do: only implement what you actually need, =
and ignore those unrelated details.
Also, trying to faithfully and completely reproduce the consensus code =
in a wallet (even if you don=E2=80=99t need that at all) could be =
extremely dangerous. Such wallet might be tricked, for example, to sign =
the hash =E2=80=9Cone=E2=80=9D and get all money stolen (I was told =
someone really did that, but I don=E2=80=99t know the details)
If you didn=E2=80=99t implement OP_CODESEPARATOR because you didn=E2=80=99=
t use it, there is no reason for you to fully implement OP_MASKEDPUSH =
nor script parsing. In existing signature schemes (e.g. BIP143), =
signatures always commit to the script being executed (the =
=E2=80=9CscriptCode=E2=80=9D). I assume that all wallets would =
re-construct the scriptCode at signing time, based on the limited set of =
script templates they support. If a wallet had a function called =
GetScriptCodeForMultiSig() for this purpose, all they need now is a =
GetMaskedScriptCodeForMultiSig() that returns the masked template, or a =
new option in the existing GetScriptCodeForMultiSig(). It does not need =
to be something like GetMaskedScript(GetScriptCodeForMultiSig()). After =
all, only a very small number of script templates really need NOINPUT. A =
GetMaskedScript() in a wallet is just an overkill (and a vulnerability =
if mis-implemented)=20
>=20
> Bitcoind developers are not in a good position to assess complexity
> here. They have to implement *everything*, so each increment seems
> minor. In addition, none of these new script versions will ever make
> bitcoind simpler, since they have to support all prior ones. Wallets,
> however, do not have to.
>=20
> I also think that minimal complexity for (future) wallets is an
> underappreciated feature: the state of wallets in bitcoin is poor[3]
> so simplicity should be a key goal.
It is a 3-way tradeoff of security, complexity, and functionality. While =
not everyone might appreciate this, security seems to always be the =
dominent factor in bitcoin protocol development. It was the reason why =
most core contributors were hesitant towards BIP148, despite they all =
love the functionality of segwit.
It=E2=80=99s also about functionality here: as I mentioned in another =
reply, OP_CODESEPARATOR couldn=E2=80=99t function properly with NOINPUT =
but without OP_MASKEDPUSH
This debate happens because NOINPUT introduces the third way to lose =
fund with key reuse. And once it is deployed, we have to support it =
forever, and is not something that we could softfork it away.
>=20
> Respectfully,
> Rusty.
>=20
> [1] Reusing your revocation base point across two channels will lose
> funds in a much more trivial way, as will reusing payment hashes
> across invoices.
> [2] In fact, I added SIGHASH_ANYONECANPAY and SIGHASH_SINGLE recently
> for Segwit and it worked first time! Kudos to BIP143's authors for
> such a clear guide.
> [3] Bitcoind's wallet can't restore from seed; this neatly =
demonstrates
> how hard the wallet problem is, but there are many others.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> code, as modern wallets currently don't have to parse the scripts they
> sign.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> I'm telling you that this is not how people are losing funds.
>=20
>=20
>=20
>>=20
>> Also, saying "I can't see how to break this, so it's probably good
>> enough, even if other people have a bad feeling about it" is a crypto
>> anti-pattern, isn't it?
>>=20
>> I don't see how you could feasibly commit to more information than =
script
>> masking does for use cases where you want to be able to spend =
different
>> scripts with the same signature [0]. If that's possible, I'd probably
>> be for it.
>>=20
>> At the same time, script masking does seem feasible, both for
>> lightning/eltoo, and even for possibly complex variations of scripts. =
So
>> committing to less doesn't seem wise.
>>=20
>>> You already need both key-reuse and amount-reuse to be exploited.
>>> SIGHASH_MASK only prevents you from reusing this input for a =
"normal"
>>> output; if you used this key for multiple scripts of the same form,
>>> you're vulnerable[1].
>>=20
>> For example, script masking seems general enough to prevent footguns
>> even if (for some reason) key and value reuse across eltoo channels
>> were a requirement, rather than prohibited: you'd make the script be
>> "<eltoo-channel-id> MASK <statenum> CLTV 2DROP <a+b> CHECKSIG", and =
your
>> signature will only apply to that channel, even if another channel =
has
>> the same capacity and uses the same keys, a and b.
>>=20
>>> So I don't think it's worth it. SIGHASH_NOINPUT is simply dangerous
>>> with key-reuse, and Don't Do That.
>>=20
>> For my money, "NOINPUT" commits to dangerously little context, and
>> doesn't really feel safe to include as a primitive -- as evidenced by
>> the suggestion to add "_UNSAFE" or similar to its name. Personally, =
I'm
>> willing to accept a bit of risk, so that feeling doesn't make me =
strongly
>> against the idea; but it also makes it hard for me to want to support
>> adding it. To me, committing to a masked script is a huge =
improvement.
>>=20
>> Heck, if it also makes it easier to do something safer, that's also
>> probably a win...
>>=20
>> Cheers,
>> aj
>>=20
>> [0] You could, perhaps, commit to knowing the private keys for all =
the
>> *outputs* you're spending to, as well as the inputs, which comes
>> close to saying "I know this is a scary NOINPUT transaction, but
>> we're paying to ourselves, so it will all be okay".
>> _______________________________________________
>> 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
|