From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B3E84BE6 for ; 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 ; 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= header.from= 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 In-Reply-To: <20181218045826.2latx2rdyzsuc77k@erisian.com.au> Date: Tue, 18 Dec 2018 18:00:59 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20181214104839.ur4lde3dzncadmr4@erisian.com.au> <20181218045826.2latx2rdyzsuc77k@erisian.com.au> To: Anthony Towns 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 10:01:15 -0000 > On 18 Dec 2018, at 12:58 PM, Anthony Towns 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 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 " CLTV

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

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