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
|
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 688C840C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Dec 2018 16:34:19 +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 B62BDA8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Dec 2018 16:34:18 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545582839; cv=none; d=zoho.com; s=zohoarc;
b=dLNYZ9BaA4Ye4R0pgLP1zbXVbMYLqT6NUkV/VYQdWuiSoayBXXfzoAxQhsGly6+319rOFYlXAEW3pba2XKw98d3hKvgY0bdsp/bSKaFUWN8HKCb/I7wTTcHpWgCNbvHC8iWjzJdZyy4GjWYvkQJLZIAz8TpIStyG4ks8vTQPweU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1545582839;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=sLuARgf6icZJ9h2EU2goD5cav79/QYCdjOfpyKXuzLI=;
b=goaow0MsBIPIMCE+2++TU+Fpt8GpDwJs+2ZJySQxbc9i0+bvm7+0n5/9PLmMKQ5zsd8b8qYGc7tIkAinU7FlQdVFfPtk5E/n0SMYSBkjl4kHLDBurKzl/1qbFBX/ng08TcL4XTRtYKlZ0TYEXk9y8W4DI1PfooMBKjOrGqJ0aC4=
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 1545582835711209.37520501634015;
Sun, 23 Dec 2018 08:33:55 -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: <20181223042659.munrqfe4l6nff2ug@erisian.com.au>
Date: Mon, 24 Dec 2018 00:33:48 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F445FD1D-52E2-41E4-8FBD-3419A6317CF6@xbt.hk>
References: <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>
<73F32BC6-751E-4F35-BE6D-B31170FC0A54@xbt.hk>
<20181223042659.munrqfe4l6nff2ug@erisian.com.au>
To: Anthony Towns <aj@erisian.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: Sun, 23 Dec 2018 18:43:54 +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: Sun, 23 Dec 2018 16:34:19 -0000
> On 23 Dec 2018, at 12:26 PM, Anthony Towns <aj@erisian.com.au> wrote:
>=20
> On Sat, Dec 22, 2018 at 02:54:42AM +0800, Johnson Lau wrote:
>> 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
>=20
> If you don't have conditionals, then I think committing to the =
(masked)
> script gives you everything you could do with codeseparator.
I don=E2=80=99t think CODESEPARATOR is useful without conditionals. By =
useful I mean making a script more compact
>=20
> If you don't commit to the (masked) script, don't have conditionals,
> and don't have codeseparator, then I don't think you can make a =
signature
> distinguish which alternative script it's intending to sign; but you =
can
> just give each alternative script in the MAST a slight variation of =
the
> key and that seems good enough.
You can and should always use a different in different branch. If this =
best practice is always followed, committing to masked script is not =
necessary
>=20
> OTOH, I think for (roughly) the example you gave:
>=20
> DEPTH 3 EQUAL
> IF <Bob> CHECKSIGVERIFY HASH160 <H> EQUALVERIFY CODESEP
> ELSE <n> CLTV DROP
> ENDIF
> <Alice> CHECKSIG
>=20
> then compared to the taproot equivalent:
>=20
> P =3D muSig(Alice,Bob)
> S1 =3D <Alice1> CHECKSIGVERIFY <Bob> CHECKSIGVERIFY HASH160 <H> EQUAL
> S2 =3D <Alice2> CHECKSIGVERIFY <n> CLTV
>=20
> the IF+CODESEP approach is actually cheaper (lighter weight) if you're
> mostly (>2/3rds of the time) taking the S1 branch. This is because the
> "DEPTH 3 EQUAL IF/ELSE/ENDIF CODESEP <n> CLTV DROP" overhead is less
> than the 32B overhead to choose a merkle branch).
>=20
> (That said, I'm not sure what Alice's signature in the S1 branch =
actually
> achieves in that script; and without that in S1, the taproot approach =
is
> cheaper all the time. Scriptless scripts would be cheaper still)
>=20
>> If no one needs CODESEPARATOR, we might just disable it, and makes =
the validation code a bit simpler
>=20
> Since it only affects the behaviour of the checkdls (checksig) =
operators,
> even if it was disabled, it could be re-enabled fairly easily in a new
> script subversion if needed (ie, it could be re-added when upgrading
> witness version 1 from script version 0 to 1).
>=20
> Cheers,
> aj
>=20
Yes, I don=E2=80=99t think it needs Alice signature in S1 at all. So the =
original example doesn=E2=80=99t even need CODESEPARATOR at all.=20
Could anyone propose a better use case of CODESEPARATOR?
|
