Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.171 as permitted sender)
	client-ip=209.85.212.171; envelope-from=oleganza@gmail.com;
	helo=mail-wi0-f171.google.com; 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Oleg Andreev <oleganza@gmail.com>
In-Reply-To: <20150427191855.GE5223@muck>
Date: Tue, 28 Apr 2015 12:17:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B4C8493-CD37-4D43-ABF1-0AA5388CD78E@gmail.com>
References: <552EF785.7000207@sky-ip.org>
	<CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com>
	<552FDF73.6010104@sky-ip.org>
	<CABjHNoTeMiLWkDBUqdV4HJ=nAhj8wqOjD4cypY9Dv2y9HJWJMg@mail.gmail.com>
	<CABHVRKTMg3sih8i3ta0v=jZU+fBzBR-i5b_b7C+drV4CAfGQJg@mail.gmail.com>
	<20150427191855.GE5223@muck>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Precedence: list


> On 27 Apr 2015, at 21:21, Peter Todd <pete@petertodd.org> wrote:
>=20
> Even right now there are edge cases without
> good solutions, like how in a multisig environment any of the key
> holders can mutate transactions.

Can't we add requirement for RFC6979 signatures to mitigate this? Of =
course, multiple signers can still mutate transaction by choosing a =
different set (but not the order, thankfully) of signatures. Or when a =
single signer has multiple participating keys.

In some interesting to me scenarios mutation by signer is not critical: =
it is mutation by non-signers that creates a problem. Do you know of any =
edge cases when non-signers can mutate transactions which are not =
covered by BIP62? What would be a more robust approach than =
"whack-a-mole" to work around mutability? (Normalized tx ids?)=