1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
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=
|
