Content-Type: text/plain;
	charset=gb2312
Mime-Version: 1.0 (1.0)
From: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <CAMZUoK=heF1FALyGbi7cpzLiQuhLnsq-5Z2-sTgq5b28sjjeUw@mail.gmail.com>
Date: Sun, 1 Oct 2017 13:39:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC800737-7B93-41BD-BA87-F25B25F95426@friedenbach.org>
References: <201710010113.30518.luke@dashjr.org>
	<5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org>
	<201710010247.42180.luke@dashjr.org>
	<D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org>
	<CAMZUoK=1fZUeKkA6V2pFwqj-Fd-YnZD4sffP9yc0Y7vv8-XvhQ@mail.gmail.com>
	<460EDF1F-2BFD-4DBE-A921-73469C2EA9B9@friedenbach.org>
	<CAMZUoK=heF1FALyGbi7cpzLiQuhLnsq-5Z2-sTgq5b28sjjeUw@mail.gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
Precedence: list


> On Oct 1, 2017, at 12:41 PM, Russell O'Connor <roconnor@blockstream.io> wr=
ote:
>=20
> Creating a Bitcoin script that does not allow malleability is difficult an=
d requires wasting a lot of bytes to do so, typically when handling issues a=
round non-0-or-1 witness values being used with OP_IF, and dealing with non-=
standard-zero values, etc.

Script validation flags of the correct place to do this. We already have pol=
icy validation flags that check for these things. They were not made consens=
us rules with Segwit v0 mainly due to concern over scope creep in an already=
 large overhaul, of my memory is correct. Script versions and quadratic hash=
ing fixes where the minimum necessary to allow segwit to activate safely whi=
le still enabling future upgrades that would otherwise have been hard forks.=
 We knew that we would be later changing the EC signature scheme to be somet=
hing that supported signature aggregation, and that would be more appropriat=
e time to discuss such changes. As we are considering to do now (although wi=
tness versions means we don=A1=AFt need to omnibus the script upgrade here e=
ither, so a v1 before signature aggregation is ready is fine IMHO).

In any case if there is any general witness malleability due to opcode seman=
tics that it=A1=AFs not fixed by one of our existing policy flags, that is a=
 bug and I would encourage you to report it.
> I'll argue that I don't want my counter-party going off and using a very d=
eeply nested key in order to subvert the fee rate we've agreed upon after I'=
ve signed my part of the input.  If we are doing multi-party signing of inpu=
ts we need to communicate anyways to construct the transaction.  I see no pr=
oblem with requiring my counter-party to choose their keys before I sign so t=
hat I know up front what our fee rate is going to be.  If they lose their ke=
ys and need a backup, they should have to come back to me to resign in order=
 that we can negotiate a new fee rate for the transaction and who is going t=
o be covering how much of the fee and on which inputs.

Arguing that every single user should be forced to restart an interactive si=
gning session. That=A1=AFs a very strong statement based on something that I=
 would say is a preference that depends on circumstances.

What about an optional commitment to witness size in bytes? The value zero m=
eaning =A1=B0I don=A1=AFt care.=A1=B1 I would argue that it should be a maxi=
mum however, and therefor serialized as part of the witness. The serializati=
on of this would be very compact (1 plus the difference between actual and m=
aximum, with zero meaning not used.)=