Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.68 as permitted sender)
	client-ip=74.125.82.68;
	envelope-from=stephencalebmorse@gmail.com;
	helo=mail-wg0-f68.google.com; 
MIME-Version: 1.0
In-Reply-To: <CABjHNoTeMiLWkDBUqdV4HJ=nAhj8wqOjD4cypY9Dv2y9HJWJMg@mail.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>
Date: Sat, 25 Apr 2015 10:32:36 -0400
Message-ID: <CABHVRKTMg3sih8i3ta0v=jZU+fBzBR-i5b_b7C+drV4CAfGQJg@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: William Swanson <swansontec@gmail.com>
Content-Type: multipart/alternative; boundary=f46d044304405d298805148d62b8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Precedence: list

--f46d044304405d298805148d62b8
Content-Type: text/plain; charset=UTF-8

Hi William,

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

The two are complementary, not competing. BIP62 prevents *non-signers* from
mutating the transactions, which is very important. The 'Build your own
nHashType' proposal enables chained transactions even in the face of
*signers* mutating the transaction. I believe that integrating both will
lead to the best defense against transaction malleability, and will enable
more complicated uses of chained transactions (such as micropayment
channels).

Best,
Stephen

--f46d044304405d298805148d62b8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi William,<div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">I personally prefer this so=
lution, since it nails the problem<br>
completely with one simple and obvious change. The BIP 62 approach is<br>
more like a game of wac-a-mole.<br></blockquote><div><br></div><div>The two=
 are complementary, not competing. BIP62 prevents <b>non-signers</b> from m=
utating the transactions, which is very important. The &#39;Build your own =
nHashType&#39; proposal enables chained transactions even in the face of <b=
>signers</b> mutating the transaction. I believe that integrating both will=
 lead to the best defense against transaction malleability, and will enable=
 more complicated uses of chained transactions (such as micropayment channe=
ls).</div><div><br></div><div>Best,</div><div>Stephen</div><div><br></div><=
div><br></div></div></div></div></div>

--f46d044304405d298805148d62b8--