Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.176 as permitted sender)
	client-ip=209.85.213.176; envelope-from=gmaxwell@gmail.com;
	helo=mail-ig0-f176.google.com; 
MIME-Version: 1.0
In-Reply-To: <20141106231225.GA26859@savin.petertodd.org>
References: <20141106213215.GA12918@savin.petertodd.org>
	<A53D2C60-1D6A-4796-9776-3AF396BEC9F1@bitsofproof.com>
	<545BF0C2.3030201@bluematt.me>
	<20141106231225.GA26859@savin.petertodd.org>
Date: Fri, 7 Nov 2014 02:04:57 +0000
Message-ID: <CAAS2fgQ6rtMdbq9SYFfthJiZW040dg=qzbNLP=HMmgoxszB8Hw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] The difficulty of writing consensus
 critical code: the SIGHASH_SINGLE bug
Precedence: list

On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd <pete@petertodd.org> wrote:
> BIP62 does make life easier for wallet authors as they don't have to
> deal with malleability - maybe! -

Yes, I agree for most contract purposes CTLV is what you want to be
using, instead of refund transactions beyond being more clearly
correct, it shrinks the protocol state machine by one step.

Though BIP62 also achieves the secondary goal of making required
implementation behaviour more explicit (e.g. the parts enforced in all
transactions), and that shouldn't be discounted.

They're somewhat orthogonal, somwhat complementary things.