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 994674A3 for ; Sun, 1 Oct 2017 21:33:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0929E3D5 for ; Sun, 1 Oct 2017 21:33:02 +0000 (UTC) Received: from [10.8.0.102] (119246244201.ctinets.com [119.246.244.201]) by mx.zohomail.com with SMTPS id 1506893580388543.6475827603573; Sun, 1 Oct 2017 14:33:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Johnson Lau In-Reply-To: <201710010113.30518.luke@dashjr.org> Date: Mon, 2 Oct 2017 05:32:56 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <30B31B43-B603-4793-BDFB-B7E25FD96D1B@xbt.hk> References: <201710010113.30518.luke@dashjr.org> To: Luke Dashjr , bitcoin-dev X-Mailer: Apple Mail (2.3445.1.6) X-ZohoMailClient: External X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft) 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: Sun, 01 Oct 2017 21:33:03 -0000 So there are 3 proposals with similar goal but different designs. I try = to summarise some questions below: 1. How do we allow further upgrade within v1 witness? Here are some = options: a. Minor version in witness. (Johnson / Luke) I prefer this way, but we = may end up with many minor versions. b. OP_RETURNTRUE (Luke). I proposed this in an earlier version of BIP114 = but now I think it doesn=E2=80=99t interact well with signature = aggregation, and I worry that it would have some other unexpected = effects. c. Generalised NOP method: user has to provide the returned value, so = even VERIFY-type code could do anything 2. Do we want to allow signature-time commitment of extra scripts? I think all proposals allow this, just with different way a. Tail-call semantics with CHECKSIGFROMSTACK (Mark). I think this is = too rigid as it works only with specially designed scriptPubKey b. scriptWitCode: extra scripts are put in some fixed location in = witness (Johnson). This makes sure static analysability. c. Extra-data as script in OP_CHECKSIG (Luke) 3. Do we want to allow static analysis of sigop? BIP114 and the related proposals are specifically designed to allow = static analysis of sigop. I think this was one of the main reason of = OP_EVAL not being accepted. This was also the main reason of Ethereum = failing to do a DAO hacker softfork, leading to the ETH/ETC split. I=E2=80= =99m not sure if we really want to give up this property. Once we do it, = we have to support it forever. =E2=80=94=E2=80=94 Johnson=