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>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade
Precedence: list


> 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.=