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
|
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 B3E84BE6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Dec 2018 10:01:15 +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 8219D782
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Dec 2018 10:01:14 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545127266; cv=none; d=zoho.com; s=zohoarc;
b=ChUfANp7XKcYD9OkKriHX0VEaFM0iORU2YKoaC4xzN7RPC3rvVbuOU35084k0UNLLMyPUJyBkeau/Zpr3Bp/I4ppLerL7zf7uyZZYSlVyzyThmIlyh1Xo57OtA4vD4cWL7WjmzxH79j2hGgAYydBxsWc9Gdma94I6Z9299V03q4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1545127266;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=yEaLiiIPudkAwjXX+6cDWdwEvaEmmO/VVu1spHRQ7yM=;
b=le5xW5DrBgUwGPHd/TPSqbPDFIfquB/fp7M7N/47KSIVGcHLeCRY50IsmnSjWCEU22q0s5AiEBI6okWetzkG1Hdme96ruQ8BRsDevDmFPoh+Jv8CmaEuKd6lJcnCVWhz8Z28llxwrJkIghUd+hYQSVUaRkugtgCTHUTKaxTzZn8=
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 1545127265107672.285619695873;
Tue, 18 Dec 2018 02:01:05 -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: <20181218045826.2latx2rdyzsuc77k@erisian.com.au>
Date: Tue, 18 Dec 2018 18:00:59 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B26BB224-A684-495C-A419-A8CB5947AAC4@xbt.hk>
References: <20181214104839.ur4lde3dzncadmr4@erisian.com.au>
<CAMZUoKnSi+8W7znTNv4BcjrrTDJubDeWeJ8ynUtzs04ES2z6AQ@mail.gmail.com>
<E07C0182-1656-44B0-AD2E-8EAF9552ECC1@xbt.hk>
<CAMZUoKnc+0pBCP84RoezKrNMrsm2oK4XX=U9-B0Oyo4ELdiEJA@mail.gmail.com>
<20181218045826.2latx2rdyzsuc77k@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: Tue, 18 Dec 2018 16:11:00 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade
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: Tue, 18 Dec 2018 10:01:15 -0000
> On 18 Dec 2018, at 12:58 PM, Anthony Towns <aj@erisian.com.au> wrote:
>=20
> On Mon, Dec 17, 2018 at 10:18:40PM -0500, Russell O'Connor wrote:
>> On Mon, Dec 17, 2018 at 3:16 PM Johnson Lau <jl2012@xbt.hk> wrote:
>> But I=E2=80=99m not sure if that would do more harm than good. For =
example, people
>> might lose money by copying an existing script template. But they =
might
>> also lose money in the same way as CHECKMULTISIG is disabled. So =
I=E2=80=99m not
>> sure.
>=20
> Well, if CHECKSIG* and CHECKMULTISIG* are all disabled in favour of
> CHECKDLS, CHECKDLSVERIFY and CHECKDLSADD with both different names and
> different opcodes, copying a script template opcode-for-opcode from v0
> to v1 will always fail. (With taproot, this doesn't necessarily mean =
you
> lose money, even if the script is impossible to ever satisfy, since =
you
> may be able to recover via the direct signature path)
>=20
>> Another related thing I=E2=80=99d like to bikeshed is to pop the =
stack after
>> OP_CLTV and OP_CSV. The same pros and cons apply.
>> This one is almost a no-brainer I think. Nearly every instance of =
OP_CSV is
>> followed by an OP_DROP and we'd save 1 WU per OP_CSV if we pop the =
stack
>> afterwards.
>=20
> It's definitely bikeshedding so whatever; but to me, it seems like =
it'd
> be easier for everyone to have it so that if you've got the same =
opcode
> in v0 script and v1.0 script; they have precisely the same semantics.
>=20
> (That said, constructions like "<n> CLTV <p> CHECKSIGVERIFY" that =
avoid
> the DROP and work when you're expected to leave a true value on the
> stack won't work if you have to end up with an empty stack)
>=20
> Cheers,
> aj
>=20
I think you mean <p> CHECKSIGVERIFY <n> CLTV, but this works only for =
simple script. Most likely you need a DROP if you use IF or =
CODESEPARATOR.
However, if we change the rule from =E2=80=9Cone true stack item=E2=80=9D =
to =E2=80=9Cempty stack=E2=80=9D, CLTV/CSV popping stack will make more =
sense. So I think either we change all, or change nothing.
The =E2=80=9Ctrue stack item=E2=80=9D and CLTV/CSV as NOP are tech debt. =
Fixing them in new script version makes script creation easier and =
sometimes cheaper, but the fix itself creates further tech debts in the =
code. So I don=E2=80=99t have strong opinion on this topic.=
|