Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <B8C5E7EF-9062-4431-9B63-06FF855B1D78@xbt.hk>
Date: Wed, 20 Sep 2017 12:29:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <34163C93-5F2C-4DC8-9FB2-7E28805C0184@friedenbach.org>
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>
To: Johnson Lau <jl2012@xbt.hk>
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)
Precedence: list


> 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.

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.

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.

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.

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.

Mark=