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 41DDDD1F for ; Mon, 17 Dec 2018 20:16:25 +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 D7B077A4 for ; Mon, 17 Dec 2018 20:16:24 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1545077778; cv=none; d=zoho.com; s=zohoarc; b=hfOIqMujkBzKGW8cvkjcbNO5UpPuVdal0fRyFFwR3XliFOfCWwR4WSFCkj5uR3PBRFbqSK10Pu7QpS/BTPZivUN68T0G4CcrKIlkq8rV8n4dKLBANQC6kZbNSy0d/uF7Gj5H2bip0rmnnyGR2UDlU+JMFTjUBNK4bCGIQJgMzlY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1545077778; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=pxVK9NHo8XcWQYZM/mDukZwWwlLRBVAABDw9UdyibIM=; b=fzotADqo5n3iocYYjswo4YjqYcGLW3lcMq6taZNjG7v7hIzcOD/az/smHXn6pbCyshLvRbvji6HtzbrrM6TEtFMt3MtNRcX5B2dMslcntJOIIdawHLKPmNXudLM+S9yiR6FcIIecxogM1UTq8WulG/eB4M6Nbdsy2znzFRU6pn0= 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 1545077776019416.37756662637923; Mon, 17 Dec 2018 12:16:16 -0800 (PST) From: Johnson Lau Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F5963007-F928-4EAA-9851-BDB567540227" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 18 Dec 2018 04:16:12 +0800 In-Reply-To: To: Russell O'Connor , bitcoin-dev References: <20181214104839.ur4lde3dzncadmr4@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,HTML_MESSAGE, 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 02:18:17 +0000 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: Mon, 17 Dec 2018 20:16:25 -0000 --Apple-Mail=_F5963007-F928-4EAA-9851-BDB567540227 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Dec 2018, at 7:38 AM, Russell O'Connor via bitcoin-dev = wrote: >=20 > On Fri, Dec 14, 2018 at 8:39 AM Anthony Towns via bitcoin-dev = > wrote: > 5. if there's exactly one, non-zero item on the stack; succeed >=20 > Unless it is too much bikeshedding, I'd like to propose that to = succeed the stack must be exactly empty. Script is more composable that = way, removing the need for special logic to handle top-level CHECKSIG, = vs mid-level CHECKSIGVERIFY. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev I proposed the same in BIP114. I wish Satoshi had designed that way. 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. 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.= --Apple-Mail=_F5963007-F928-4EAA-9851-BDB567540227 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 16 Dec 2018, at 7:38 AM, Russell O'Connor via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> wrote:

On = Fri, Dec 14, 2018 at 8:39 AM Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
      5. if there's = exactly one, non-zero item on the stack; succeed

Unless it is too much bikeshedding, I'd like to propose that = to succeed the stack must be exactly empty.  Script is more = composable that way, removing the need for special logic to handle = top-level CHECKSIG, vs mid-level CHECKSIGVERIFY.
_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

I = proposed the same in BIP114. I wish Satoshi had designed that way. 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.

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.
= --Apple-Mail=_F5963007-F928-4EAA-9851-BDB567540227--