diff options
| author | Johnson Lau <jl2012@xbt.hk> | 2017-10-02 05:32:56 +0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-10-01 21:33:03 +0000 |
| commit | 4db782fddffccd60d7121d4d0c981d84891eb892 (patch) | |
| tree | a50ed9cf21d060a610d586c2272f172e0126f8f7 | |
| parent | 44a922340201d650ad9b8d0acdf68dd2aa2bca79 (diff) | |
| download | pi-bitcoindev-4db782fddffccd60d7121d4d0c981d84891eb892.tar.gz pi-bitcoindev-4db782fddffccd60d7121d4d0c981d84891eb892.zip | |
Re: [bitcoin-dev] Version 1 witness programs (first draft)
| -rw-r--r-- | 73/a8e55305c4b92afc8eebfd7b082ac330b4dfd3 | 79 |
1 files changed, 79 insertions, 0 deletions
diff --git a/73/a8e55305c4b92afc8eebfd7b082ac330b4dfd3 b/73/a8e55305c4b92afc8eebfd7b082ac330b4dfd3 new file mode 100644 index 000000000..de36df941 --- /dev/null +++ b/73/a8e55305c4b92afc8eebfd7b082ac330b4dfd3 @@ -0,0 +1,79 @@ +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 994674A3 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <jl2012@xbt.hk> +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 <luke@dashjr.org>, + bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> +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 <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: 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= + + |