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
|
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 AB0C7DC8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Dec 2018 13:56:04 +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 E882C177
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Dec 2018 13:56:03 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1544795749; cv=none; d=zoho.com; s=zohoarc;
b=gFFKJ0v3YSr3wMFKWXbIabPhTlk814Dbx5OKjP+qfapxCqZLo0y26KqbyuzJwzop/hRsvAn/5U1cQyn0O2ioGgw1vdsYaupu9uwj3iefmLWzT8aIyAU7JhkA/+ygy7C2qyaU+ocp9fJiHfKMU+deArGunzQkzAEmdWeZkI5wK/8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1544795749;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=/Q3+vCDxVgq7Gp4XPC4rf5nX1UIAYD+PRwPnS5PX/hw=;
b=QhWC4AXetoWrC+LcYnvcQkjlqhK5jh1jc9K4eJX7go8QOQQrBLa0v7ouvUD/82Ohugnr/1y8uznS1SzkLeZdPVL6YSUPfbgjSds0xA/KKdUGb6/tMqMC/s3hHgbzIhR9CuagyNuMY+iyciamVq00xVC9XcnaLv4yQbYA7w+aakQ=
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 1544795747619590.9878790388967;
Fri, 14 Dec 2018 05:55:47 -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: <20181214093002.p2nvfrlaycqblww3@erisian.com.au>
Date: Fri, 14 Dec 2018 21:55:43 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F9FE2267-0BCB-4C67-9AE8-3285B7459D51@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>
To: Anthony Towns <aj@erisian.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: 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: Fri, 14 Dec 2018 13:56:04 -0000
I don=E2=80=99t think this has been mentioned: without signing the =
script or masked script, OP_CODESEPARATOR becomes unusable or insecure =
with NOINPUT.
In the new sighash proposal, we will sign the hash of the full script =
(or masked script), without any truncation. To make OP_CODESEPARATOR =
works like before, we will commit to the position of the last executed =
OP_CODESEPARATOR. If NOINPUT doesn=E2=80=99t commit to the masked =
script, it will just blindly committing to a random OP_CODESEPARATOR =
position, which a wallet couldn=E2=80=99t know what codes are actually =
being executed.
> On 14 Dec 2018, at 5:30 PM, Anthony Towns via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> 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
> 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
|
