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
|
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 71AC6E89
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 18:55:06 +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 6E8E9832
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Dec 2018 18:55:05 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545418490; cv=none; d=zoho.com; s=zohoarc;
b=MkeSgpFp2hOZdvIjDby5j/RBLKxRSQbJ7AQZQ75eFPYMTgYvWNoT+Uoiuc8uqU5Cht3lkMusfDmlZLN3EVy8Y1+SK5L2eYOqNwyCVtinYi2CPdODRNNFz1tu/0+CtxWdEyw5Jm6ylfAu/1WFpJ++sPUYDss1LmFK03VlJM12GgU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1545418490;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=Ad7+zE2n5AApMM13qJ6MhB3v4JHOce3DuVbizeuO6Jo=;
b=DKrJU8F+ekGzLqlYVwmEXHmvRv6KXPnz1RPPfUty7XEsmlDEDValWUgNIQSHz5+xRkHhp9GOKhNiF0zDaoPsHjbsOH6t1MFgZcxK5z4AspVXVVdB39Q9B/m1RrYjKjGKdgRbEXx7BDPucQ91DCTgOHINa/S7ydZf/Vk4Bjg9HdI=
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 1545418488831772.199390789455;
Fri, 21 Dec 2018 10:54:48 -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: <87y38jn5z8.fsf@rustcorp.com.au>
Date: Sat, 22 Dec 2018 02:54:42 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <73F32BC6-751E-4F35-BE6D-B31170FC0A54@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>
<F9FE2267-0BCB-4C67-9AE8-3285B7459D51@xbt.hk>
<87mup4hmq5.fsf@rustcorp.com.au>
<2302A26C-FB9C-47D2-AF6C-4D2EF02FFAC0@xbt.hk>
<87y38jn5z8.fsf@rustcorp.com.au>
To: Rusty Russell <rusty@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,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: Fri, 21 Dec 2018 23:30:36 +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: Fri, 21 Dec 2018 18:55:06 -0000
> On 21 Dec 2018, at 7:17 AM, Rusty Russell <rusty@rustcorp.com.au> =
wrote:
>=20
> Johnson Lau <jl2012@xbt.hk> writes:
>=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
>>=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.
>>=20
>> 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
>=20
> Yes, I read this as proposed, it is clever. Not sure we'd be
> introducing it if OP_CODESEPARATOR didn't already exist, but at least
> it's a simplfication.
>=20
>> In the case of NOINPUT with MASKEDSCRIPT, it will commit to the =
H(masked_script) instead of H(script).
>>=20
>> 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.
>>=20
>> 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.
>=20
> My question is more fundamental. If NOINPUT doesn't commit to the =
input
> at all, no script, no code separator, nothing. I'm struggling to
> understand your original comment was "without signing the script or
> masked script, OP_CODESEPARATOR becomes unusable or insecure with
> NOINPUT."
>=20
> I mean, non-useful, sure. Its purpose is to alter signature behavior,
> and from the script POV there's no signature with this form of =
NOINPUT.
> But other than the already-established "I reused keys for multiple
> outputs" oops, I don't see any new dangers?
>=20
> Thanks,
> Rusty.
The question I would like to ask is: is OP_CODESEPARATOR useful under =
taproot? Generally speaking, CODESEPARATOR is useful only with =
conditional opcodes (OP_IF etc), and conditional opcodes are mostly =
replaced by merklized scripts. I am not sure how much usability is left =
with CODESEPARATOR
If no one needs CODESEPARATOR, we might just disable it, and makes the =
validation code a bit simpler
If CODESEPARATOR is useful, then we should find a way to make it works =
with NOINPUT. With H(masked_script) committed, the meaning of the =
CODESEPARATOR position is very clear. Without H(masked_script), the =
meaning of the position totally relies on the assumption that =E2=80=9Cthi=
s public key is only used in this script template=E2=80=9D.
Ignore CODESEPARATOR and more generally, I agree with you that script =
masking does not help in the case of address (scriptPubKey) reuse, which =
is the commonest type of reuse. However, it prevents replayability when =
the same public key is reused in different scripts=
|
