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
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
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 63A1640A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Sep 2017 03:58:15 +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 901C343A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 21 Sep 2017 03:58:14 +0000 (UTC)
Received: from [192.168.1.139] (137.189.135.167 [137.189.135.167]) by
mx.zohomail.com with SMTPS id 1505966290329705.2595777171889;
Wed, 20 Sep 2017 20:58:10 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <34163C93-5F2C-4DC8-9FB2-7E28805C0184@friedenbach.org>
Date: Thu, 21 Sep 2017 11:58:05 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <02DA3C1D-2892-4D27-B646-A6E002C5DB12@xbt.hk>
References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org>
<C623794E-F061-4C7A-B05D-378798ED2BF7@friedenbach.org>
<201709190309.08669.luke@dashjr.org>
<B8C5E7EF-9062-4431-9B63-06FF855B1D78@xbt.hk>
<34163C93-5F2C-4DC8-9FB2-7E28805C0184@friedenbach.org>
To: Mark Friedenbach <mark@friedenbach.org>
X-Mailer: Apple Mail (2.3273)
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
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] cleanstack alt stack & softfork improvements
(Was: Merkle branch verification & tail-call semantics for generalized
MAST)
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: Thu, 21 Sep 2017 03:58:15 -0000
> On 21 Sep 2017, at 3:29 AM, Mark Friedenbach <mark@friedenbach.org> =
wrote:
>=20
>=20
>> On Sep 19, 2017, at 10:13 PM, Johnson Lau <jl2012@xbt.hk> wrote:
>>=20
>> If we don=E2=80=99t want this ugliness, we could use a new script =
version for every new op code we add. In the new BIP114 (see link =
above), I suggest to move the script version to the witness, which is =
cheaper.
>=20
> To be clear, I don=E2=80=99t think it is so much that the version =
should be moved to the witness, but rather that there are two separate =
version values here =E2=80=94 one in the scriptPubKey which specifies =
the format and structure of the segwit commitment itself, and another in =
the witness which gates functionality in script or whatever else is used =
by that witness type. Segwit just unfortunately didn=E2=80=99t include =
the latter, an oversight that should be corrected on the on the next =
upgrade opportunity.
>=20
> The address-visible =E2=80=9Cscript version=E2=80=9D field should =
probably be renamed =E2=80=9Cwitness type=E2=80=9D as it will only be =
used in the future to encode how to check the witness commitment in the =
scriptPubKey against the data provided in the witness. Upgrades and =
improvements to the features supported by those witness types won=E2=80=99=
t require new top-level witness types to be defined. Defining a new =
opcode, even one with modifies the stack, doesn=E2=80=99t change the =
hashing scheme used by the witness type.
>=20
> v0,32-bytes is presently defined to calculate the double-SHA256 hash =
of the top-most serialized item on the stack, and compare that against =
the 32-byte commitment value. Arguably it probably should have hashed =
the top two values, one of which would have been the real script =
version. This could be fixed however, even without introducing a new =
witness type. Do a soft-fork upgrade that checks if the witness redeem =
script is push-only, and if so then pop the last push off as the script =
version (>=3D 1), and concatenate the rest to form the actual redeem =
script. We inherit a little technical debt from having to deal with push =
limits, but we avoid burning v0 in an upgrade to v1 that does little =
more than add a script version.
>=20
> v1,32-bytes would then be used for a template version of MAST, or =
whatever other idea comes along that fundamentally changes the way the =
witness commitment is calculated.
>=20
> Mark
This is exactly what I suggest with BIP114. Using v1, 32-byte to define =
the basic structure of Merklized Script, and define the script version =
inside the witness
Johnson=
|
