Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.172 as permitted sender)
	client-ip=209.85.220.172; envelope-from=swansontec@gmail.com;
	helo=mail-qk0-f172.google.com; 
MIME-Version: 1.0
In-Reply-To: <552FDF73.6010104@sky-ip.org>
References: <552EF785.7000207@sky-ip.org>
	<CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com>
	<552FDF73.6010104@sky-ip.org>
Date: Fri, 24 Apr 2015 12:58:45 -0700
Message-ID: <CABjHNoTeMiLWkDBUqdV4HJ=nAhj8wqOjD4cypY9Dv2y9HJWJMg@mail.gmail.com>
From: William Swanson <swansontec@gmail.com>
To: s7r@sky-ip.org
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Precedence: list

On Thu, Apr 16, 2015 at 9:12 AM, s7r <s7r@sky-ip.org> wrote:
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.

The BIP 62 approach to malleability isn't the only option. Another
approach is to sign the transaction in such a way that the input
txid's are allowed to change without invalidating the signatures. That
way, if malleability happens, you just adjust you transaction to match
and re-broadcast. That proposal is here:

https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md

The "Build your own nHashType" thread on this mailing list contains
the discussion.

I personally prefer this solution, since it nails the problem
completely with one simple and obvious change. The BIP 62 approach is
more like a game of wac-a-mole.

-William