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
|
Return-Path: <rusty@ozlabs.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8DFA625A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Dec 2018 23:37:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [203.11.71.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A0880CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Dec 2018 23:37:09 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 43J10M1FyRz9sD9; Mon, 17 Dec 2018 10:37:07 +1100 (AEDT)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
bitcoin-dev@lists.linuxfoundation.org
In-Reply-To: <20181214093002.p2nvfrlaycqblww3@erisian.com.au>
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>
Date: Sun, 16 Dec 2018 17:25:48 +1030
Message-ID: <8736qyhsej.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DATE_IN_PAST_12_24,
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: Mon, 17 Dec 2018 16:09:42 +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: Sun, 16 Dec 2018 23:37:10 -0000
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?
>
> 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.
There are many complexities we could add, each of which would prevent
loss of funds in some theoretical case.
From practical experience; reuse of private keys between lightning and
other things is not how people will lose funds[1].
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.
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.
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.
Respectfully,
Rusty.
[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.
code, as modern wallets currently don't have to parse the scripts they
sign.
I'm telling you that this is not how people are losing funds.
>
> 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?
>
> 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.
>
> 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.
>
>> 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].
>
> 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.
>
>> So I don't think it's worth it. SIGHASH_NOINPUT is simply dangerous
>> with key-reuse, and Don't Do That.
>
> 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.
>
> Heck, if it also makes it easier to do something safer, that's also
> probably a win...
>
> Cheers,
> aj
>
> [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
|
