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
|
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 23CBDD94
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Dec 2018 00:39:38 +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 6377082F
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Dec 2018 00:39:37 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 43KGHW2xbtz9s1c; Wed, 19 Dec 2018 11:39:35 +1100 (AEDT)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Johnson Lau <jl2012@xbt.hk>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <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>
<6DE5291C-629D-4080-9B0C-E18BEFA28B16@xbt.hk>
Date: Wed, 19 Dec 2018 11:09:26 +1030
Message-ID: <87efaenydd.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Wed, 19 Dec 2018 12:40:29 +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: Wed, 19 Dec 2018 00:39:38 -0000
Johnson Lau <jl2012@xbt.hk> writes:
>> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>>=20
>> Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr=
ites:
>>> 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 s=
ecurity measures are really effective, no one will get burnt. The inevitabl=
e conclusion is: every effective security measures are overkill.
>
>>=20
>> From practical experience; reuse of private keys between lightning and
>> other things is not how people will lose funds[1].
>
> So you argument seems just begging the question. Without NOINPUT, it is j=
ust impossible to lose money by key reuse, and this is exactly the topic we=
are debating.
I think we're getting confused here. I'm contributing my thoughts from
the lightning implementer's point of view; there are other important
considerations, but this is my contribution.
In *lightning* there are more ways to lose funds via secret reuse.
Meanwhile, both SIGHASH_NOINPUT and OP_MASK have the reuse-is-dangerous
property; with OP_MASK the danger is limited to reuse-on-the-same-script
(ie. if you use the same key for a non-lightning output and a lightning
output, you're safe with OP_MASK. However, this is far less likely in
practice).
I state again: OP_MASK doesn't seem to gain *lightning* any significant
security benefit.
> It does not need to be something like GetMaskedScript(GetScriptCodeForMul=
tiSig()). After all, only a very small number of script templates really ne=
ed NOINPUT. A GetMaskedScript() in a wallet is just an overkill (and a vuln=
erability if mis-implemented)=20
Our current transaction signing code is quite generic (and, if I may say
so, readable and elegant). We could, of course, special case
GetMaskedScript() for the case we need (the Eltoo examples I've seen
have a single OP_MASK at the front, which makes it trivial).
> It=E2=80=99s also about functionality here: as I mentioned in another rep=
ly, OP_CODESEPARATOR couldn=E2=80=99t function properly with NOINPUT but wi=
thout OP_MASKEDPUSH
The mailing list seems a bit backed up or something; I replied to that
in the hope you can clear my confusion on that one.
> 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, an=
d is not something that we could softfork it away.
A would use the same words to encourage you to create the simplest
possible implementation?
I don't think we disagree on philosophy, just trade-offs. And that's
OK.
Cheers,
Rusty.
|
