path: root/8b/a61913309b487c7cc5f523defc902f56f8b6e2

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A4E7F97
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  2 Oct 2017 00:35:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com
	[209.85.192.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7720DAA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  2 Oct 2017 00:35:40 +0000 (UTC)
Received: by mail-pf0-f173.google.com with SMTP id y29so2144847pff.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 01 Oct 2017 17:35:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=mcVkx4fzhFvUQBHK8sZKOVZ+etwv6IbPZHiw0mhsVUE=;
	b=WCTtt8Wi5BhgMEtQcJVOMVzdq0FvAAtYWWB/Y4k3Bws2eMwjIaAQV0r7fwxLr6Psjw
	mUUjsdpqjrdMiPd3uXHCYcWSmKpk3oXy/CGrufjWsqe95m23G3DNeVigttRJgzzY4C4B
	qg3KeZE5NFPROGhIp+ZqBupNhqU6Pbpn2u04n4DHuRyexQ/fcJeGTc0F0ruEoPZdOQvM
	AzqS0cyWG4MyhFeEfWQ8qg/JlMhhzqQcS9Az7Nqlx35WVUMLorsReqeyXdYn9I/8EVOp
	RUM8KKJjxUB5IX4SYvy1huvOkYs3UHI5QTjOWC/yKlnJswyF7/rnpf1XSSrD5DIopXtV
	C5cQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=mcVkx4fzhFvUQBHK8sZKOVZ+etwv6IbPZHiw0mhsVUE=;
	b=W7/acR+eisUWi/041bxozbDPYS9XcD83/IwN92+rcq8JvF4bQN8LJ7PmcoUoegxmIW
	lMBCSaZoJcwn3vk9q1t5rb86ngvP/8DuPx+EqTyJa9hz0kBHt7wGCVgST1k8eCSn+2E8
	M39lwSdLlnoS0M1lkl8kVgoRZmLaIkLiQwOvoAHqGXjm0BkYB3oLMmwXXZrrD1hA/ZPF
	fsK3JwdHXU2hNKYJgAsQSbQIn4xfkazLbjilsLx3ATk1yR7TyQwyOXZVNpzLg8CgRvQa
	P8pN+d0r0aOj0lfI2s0vLwXMtrbSLnFiOsXBbxSU2/HkaxqEPPn9R1yFS6elbgeHHFZJ
	u9Ng==
X-Gm-Message-State: AMCzsaUHyXPxfT3JbL1t4h6CHK7d5ErFxbarhiacnmdFWV9zv3ulhP60
	3uulzwc61sv1H/akPCFuNQmKCE8vaDI=
X-Google-Smtp-Source: AOwi7QAEH/wTJlOxvd+e4A96kAE0FToZ1mHvmB+TrrCKmFLIkRgxywNg6Mvx1SAZ3nX0hj/YgBAFsw==
X-Received: by 10.98.2.16 with SMTP id 16mr2770415pfc.248.1506904539823;
	Sun, 01 Oct 2017 17:35:39 -0700 (PDT)
Received: from ?IPv6:2601:646:8080:1291:d07f:9ead:ff74:eb2e?
	([2601:646:8080:1291:d07f:9ead:ff74:eb2e])
	by smtp.gmail.com with ESMTPSA id
	d18sm14689903pfk.11.2017.10.01.17.35.38
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 01 Oct 2017 17:35:39 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\))
From: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <30B31B43-B603-4793-BDFB-B7E25FD96D1B@xbt.hk>
Date: Sun, 1 Oct 2017 17:35:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <50CA8523-3D1A-409E-9B7D-51EA5FC4B898@friedenbach.org>
References: <201710010113.30518.luke@dashjr.org>
	<30B31B43-B603-4793-BDFB-B7E25FD96D1B@xbt.hk>
To: Johnson Lau <jl2012@xbt.hk>
X-Mailer: Apple Mail (2.3445.1.6)
X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM 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] 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: Mon, 02 Oct 2017 00:35:41 -0000


> On Oct 1, 2017, at 2:32 PM, Johnson Lau <jl2012@xbt.hk> wrote:
>=20
> So there are 3 proposals with similar goal but different designs. I =
try to summarise some questions below:
>=20
> 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.

I'm not sure I agree with the "minor version" nomenclature, or that we =
would necessarily end up with any consensus-visible fields beyond 2.  =
There are two separate soft-fork version fields that were, I think it is =
fair to say now, inappropriately merged in the "script version=E2=80=9D =
feature of segregated witness as described in BIP141.

First there is the witness type, which combined with the length of the =
commitment that follows specifies how data from the witness stack is =
used to calculate/verify the witness commitment in the scriptPubKey of =
the output being spent.  For v0 with a 20-byte hash, it says that those =
20 bytes are the HASH160 of the top element of the stack.  For v0 with a =
32-byte hash, it says that those 32 bytes are the HASH256 of the top =
element of the stack.

Second there is the script version, which is not present as a separate =
field for witness type v0.  Implicitly though, the script version for =
v0,20-byte is that the witness consists of two elements, and these are =
interpreted as a pubkey and a signature.  For v0,32-byte the script =
version is that the witness consists of 1 or more elements; with max 520 =
byte size constraints for all but the top element, which has a higher =
limit of 10,000 bytes; and the top-most element is interpreted as a =
script and executed with the modified CHECKSIG behavior defined by =
BIP141 and the CLEANSTACK rule enforced.

These are separate roles, one not being derivative of the other.  In an =
ideal world the witness type (of which there are only 16 remaining =
without obsoleting BIP141) is used only to specify a new function for =
transforming the witness stack into a commitment for verification =
purposes.  Merklized script would be one example: v2,32-byte could be =
defined to require a witness stack of at least two elements, the top =
most of which is a Merkle inclusion proof of the second item in a tree =
whose root is given in the 32-byte payload of the output.  Maybe v3 =
would prove inclusion by means of some sort of RSA accumulator or =
something.

Such a specification says nothing about the features of the subscript =
drawn from the Merkle tree, or even whether it is bitcoin script at all =
vs something else (Simplicity, DEX, RISC-V, Joy, whatever).  All that is =
necessary is that a convention be adopted about where to find the script =
version from whatever data is left on the stack after doing the witness =
type check (hashing the script, calculating a Merkle root, checking =
inclusion in an RSA accumulator, whatever).  A simple rule is that it is =
serialized and prefixed to the beginning of the string that was checked =
against the commitment in the output.

So v0,32-byte says that the top item is hashed and that hash must match =
the 32-byte value in the output.  This new v1,32-byte witness type being =
talked about in this thread would have exactly the same hashing rules, =
but will execute the resulting string based on its prefix, the script =
version, which is first removed before execution.

Sure first script version used could be a cleaned up script with a bunch =
of the weirdness removed (CHECKMULTISIG, I'm looking at you!); CLTV, =
CSV, and MBV drop arguments; disabled opcodes and unassigned NOPs become =
"return true"; etc.  Maybe v2 adds new opcodes.  But we can imagine =
script version that do something totally different, like introduce a new =
script based on a strongly-typed Merklized lambda calculus, or a RISC-V =
executable format, or whatever.

This has pragmatic implications with the separation of witness type and =
script version: we could then define a "MAST" output that proves the =
script used is drawn from a set represented by the Merkle tree.  However =
different scripts in that tree can use different versions.  It would be =
useful if the most common script is the key aggregated everyone-signs =
outcome, which looks like a regular bitcoin payment, and then =
contingency cases can be handled by means of a complicated script =
written in some newly added general computation language or a whole =
emulated RISC-V virtual machine.

> 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

I see no reason to do either. Gate new behavior based on script =
execution flags, which are set based on the script version.  Script =
versions not understood are treated as "return true" to begin with.  The =
interpreter isn't even going to try to decode the script according to =
the old rules, let alone try to execute it, so there's no reason for the =
old soft-fork compatability tricks.

The new soft-fork trick is that you increment the script version number. =
 That is all.

> 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

This is not signature-time commitment of extra script. Not without =
CHECKSIGFROMSTACK or something like it.

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

Propose these as their own script updates.  Script versioning makes such =
new features cheap.  There's no reason to create some sort of complex =
omnibus overhaul that does everything.

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

Again, this is off-topic for this thread.  I don't think a v1 witness =
type upgrade should do any of these things.  The v1 witness type should =
add a proper script version in the witness, and remove or simplify =
limits or unnecessary verification rules that are no longer necessary =
and/or hindering progress.  That=E2=80=99s it.

For example, I don't think a v1 witness version should be coupled with =
my tail-call semantics or the introduction of MERKLEBRANCHVERIFY (but if =
MBV was released already we could have it drop its arguments, which =
would be nice).  However it should drop the CLEANSTACK rule in favor of =
something else (like signatures committing to the witness depth and/or =
weight) since the tail-call BIP demonstrates it to be an impediment to =
extensibility and alternatives are not.  And it should drop the 520 byte =
push limitation, as the MBV BIP demonstrates use cases that have =
serialized proofs larger than that, like a k-of-N threshold with N=3D16.=