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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0EB2F15
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Dec 2018 04:27:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6BFE8A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Dec 2018 04:27:18 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1gavLz-0001zi-It; Sun, 23 Dec 2018 14:27:05 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Sun, 23 Dec 2018 14:26:59 +1000
Date: Sun, 23 Dec 2018 14:26:59 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Johnson Lau <jl2012@xbt.hk>
Message-ID: <20181223042659.munrqfe4l6nff2ug@erisian.com.au>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <73F32BC6-751E-4F35-BE6D-B31170FC0A54@xbt.hk>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score: -1.9
X-Spam-Score-int: -18
X-Spam-Bar: -
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY
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 04:27:19 -0000
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
If you don't have conditionals, then I think committing to the (masked)
script gives you everything you could do with codeseparator.
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.
OTOH, I think for (roughly) the example you gave:
DEPTH 3 EQUAL
IF <Bob> CHECKSIGVERIFY HASH160 <H> EQUALVERIFY CODESEP
ELSE <n> CLTV DROP
ENDIF
<Alice> CHECKSIG
then compared to the taproot equivalent:
P = muSig(Alice,Bob)
S1 = <Alice1> CHECKSIGVERIFY <Bob> CHECKSIGVERIFY HASH160 <H> EQUAL
S2 = <Alice2> CHECKSIGVERIFY <n> CLTV
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).
(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)
> If no one needs CODESEPARATOR, we might just disable it, and makes the validation code a bit simpler
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).
Cheers,
aj
|
