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
|
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 71FA81487
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Dec 2018 19:35:01 +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 B77062C4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Dec 2018 19:35:00 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545334485; cv=none; d=zoho.com; s=zohoarc;
b=XgiWopQgEEIrVRlWfva20Pl4HJC2eTk9BEbKFeMNIsn9j6D/uhP0hnw1H7RV2UZfFQEeGKt1bOLzz+5cT6OE6yKODGoHE1p0N/DYQKM5SIgcIWEt1iqDH0pHEuhzPbqgIffu7ynDWgEXSJiaYHn2j6inD6UIrIIlv7kIVjJTDzo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1545334485;
h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=FJKZBVi+TGDtp5qZtrd/RfhG05JipUr5io3nI31mm8M=;
b=TvMzddPvP3ejT994frzbR3zQGl5lC+0RpZ6kz7vf0I+DRkOlFVRrT5x8+E5CXB4Z6WUPOFn5G3ND9eXf2gz2REQmAUmCG+VxPPSo/f8TCQu85ovYjV+xH3zzl79yNnRjT0JAx0gpuX2xOKK4stxY2WHPR/YAEJ7caz126XXef8A=
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 1545334485135358.68313382752854;
Thu, 20 Dec 2018 11:34:45 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <2302A26C-FB9C-47D2-AF6C-4D2EF02FFAC0@xbt.hk>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_18858869-DFFC-4C17-A3B1-668D72B90E86"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Fri, 21 Dec 2018 03:34:38 +0800
In-Reply-To: <87mup4hmq5.fsf@rustcorp.com.au>
To: Rusty Russell <rusty@rustcorp.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>
<F9FE2267-0BCB-4C67-9AE8-3285B7459D51@xbt.hk>
<87mup4hmq5.fsf@rustcorp.com.au>
X-Mailer: Apple Mail (2.3445.100.39)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
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: Thu, 20 Dec 2018 21:58:07 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
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: Thu, 20 Dec 2018 19:35:01 -0000
--Apple-Mail=_18858869-DFFC-4C17-A3B1-668D72B90E86
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
> On 17 Dec 2018, at 11:10 AM, Rusty Russell <rusty@rustcorp.com.au> =
wrote:
>=20
> Johnson Lau <jl2012@xbt.hk> writes:
>> 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.
>>=20
>> 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.
>=20
> My anti-complexity argument leads me to ask why we'd support
> OP_CODESEPARATOR at all? Though my argument is weaker here: no wallet
> need support it.
Because it could make scripts more compact in some cases?
This is an example: =
https://github.com/bitcoin/bitcoin/pull/11423#issuecomment-333441321 =
<https://github.com/bitcoin/bitcoin/pull/11423#issuecomment-333441321>
But this is probably not a good example for taproot, as it could be more =
efficient by making the 2 branches as different script merkle leaves.
>=20
> But I don't see how OP_CODESEPARATOR changes anything here, wrt =
NOINPUT?
> Remember, anyone can create an output which can be spent by any =
NOINPUT,
> whether we go for OP_MASK or simply not commiting to the input script.
>=20
Let me elaborate more. Currently, scriptCode is truncated at the last =
executed CODESEPARATOR. If we have a very big script with many =
CODESEPARATORs and CHECKSIGs, there will be a lot of hashing to do.
To fix this problem, it is proposed that the new sighash will always =
commit to the same H(script), instead of the truncated scriptCode. So we =
only need to do the H(script) once, even if the script is very big
In the case of NOINPUT with MASKEDSCRIPT, it will commit to the =
H(masked_script) instead of H(script).
To make CODESEPARATOR works as before, the sighash will also commit to =
the position of the last executed CODESEPARATOR. So the semantics =
doesn=E2=80=99t change. For scripts without CODESEPARATOR, the committed =
value is a constant.
IF NOINPUT does not commit to H(masked_script), technically it could =
still commit to the position of the last executed CODESEPARATOR. But =
since the wallet is not aware of the actual content of the script, it =
has to guess the meaning of such committed positions, like =E2=80=9Cwith =
the HD key path m/x/y/z, I assume the script template is blah blah blah =
because I never use this path for another script template, and the =
meaning of signing the 3rd CODESEPARATOR is blah blah blah=E2=80=9D. It =
still works if the assumptions hold, but sounds quite unreliable to me.
Johnson
--Apple-Mail=_18858869-DFFC-4C17-A3B1-668D72B90E86
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 17 Dec 2018, at 11:10 AM, Rusty Russell <<a =
href=3D"mailto:rusty@rustcorp.com.au" =
class=3D"">rusty@rustcorp.com.au</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div =
class=3D"">Johnson Lau <<a href=3D"mailto:jl2012@xbt.hk" =
class=3D"">jl2012@xbt.hk</a>> writes:<br class=3D""><blockquote =
type=3D"cite" class=3D"">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.<br class=3D""><br class=3D"">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.<br class=3D""></blockquote><br class=3D"">My =
anti-complexity argument leads me to ask why we'd support<br =
class=3D"">OP_CODESEPARATOR at all? Though my argument is weaker =
here: no wallet<br class=3D"">need support it.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>Because=
it could make scripts more compact in some cases?</div><div><br =
class=3D""></div><div>This is an example: <a =
href=3D"https://github.com/bitcoin/bitcoin/pull/11423#issuecomment-3334413=
21" =
class=3D"">https://github.com/bitcoin/bitcoin/pull/11423#issuecomment-3334=
41321</a></div><div><br class=3D""></div><div>But this is probably not a =
good example for taproot, as it could be more efficient by making the 2 =
branches as different script merkle leaves.</div><div><br =
class=3D""></div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D""><div class=3D""><br class=3D"">But I don't see how =
OP_CODESEPARATOR changes anything here, wrt NOINPUT?<br =
class=3D"">Remember, anyone can create an output which can be spent by =
any NOINPUT,<br class=3D"">whether we go for OP_MASK or simply not =
commiting to the input script.<br class=3D""><br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>Let =
me elaborate more. Currently, scriptCode is truncated at the last =
executed CODESEPARATOR. If we have a very big script with many =
CODESEPARATORs and CHECKSIGs, there will be a lot of hashing to =
do.</div><div><br class=3D""></div><div>To fix this problem, it is =
proposed that the new sighash will always commit to the same H(script), =
instead of the truncated scriptCode. So we only need to do the H(script) =
once, even if the script is very big</div><div><br =
class=3D""></div><div>In the case of NOINPUT with MASKEDSCRIPT, it will =
commit to the H(masked_script) instead of H(script).</div><div><br =
class=3D""></div><div>To make CODESEPARATOR works as before, the sighash =
will also commit to the position of the last executed CODESEPARATOR. So =
the semantics doesn=E2=80=99t change. For scripts without CODESEPARATOR, =
the committed value is a constant.</div><div><br class=3D""></div><div>IF =
NOINPUT does not commit to H(masked_script), technically it could still =
commit to the position of the last executed CODESEPARATOR. But since the =
wallet is not aware of the actual content of the script, it has to guess =
the meaning of such committed positions, like =E2=80=9Cwith the HD key =
path m/x/y/z, I assume the script template is blah blah blah because I =
never use this path for another script template, and the meaning of =
signing the 3rd CODESEPARATOR is blah blah blah=E2=80=9D. It still works =
if the assumptions hold, but sounds quite unreliable to =
me.</div><div><br class=3D""></div><div>Johnson</div></div><br =
class=3D""></body></html>=
--Apple-Mail=_18858869-DFFC-4C17-A3B1-668D72B90E86--
|
