Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.178 as permitted sender)
	client-ip=209.85.213.178; envelope-from=gmaxwell@gmail.com;
	helo=mail-ig0-f178.google.com; 
MIME-Version: 1.0
In-Reply-To: <CALqxMTHN4G1HO-7_0Fot943KK-GGOfK9gXDBqaKyyRngiXbuFQ@mail.gmail.com>
References: <20141001130826.GM28710@savin.petertodd.org>
	<CABbpET8_FMCcnh0dELnHsYmF+YP05Gz=nZ3SPkLZuqXYV3JUpQ@mail.gmail.com>
	<1987325.zKPNeYyO8K@crushinator>
	<201410031750.27323.luke@dashjr.org>
	<CANEZrP1eGi-AHgciQiKUuUB7WwqKsMOyTjCQAAO=RWEkPC2Uiw@mail.gmail.com>
	<CAJHLa0NRNEQLqA2E=ysXsKw6hWS-H9X_AFYK4ckC4-_Bk=qbSA@mail.gmail.com>
	<20141004003850.GA23202@muck>
	<CANEZrP0_jDouDCLn9BvxUd7UYiZLbVsaGGkkxwjcOYxZryBDPQ@mail.gmail.com>
	<CABsx9T0Q8g9KYRbAvCV=35x5Rb5HFnrNkrwwMZ=Mv-namMEPpg@mail.gmail.com>
	<CANEZrP2Xp7ene+KDw_L_YnNW=hDt9K-UigvZ6PLb3oUviOr_Tw@mail.gmail.com>
	<CA+s+GJC2v+g-SWvqdaD2Fb7bb4DkWTtp+e4QNRGvCo1QtraFnQ@mail.gmail.com>
	<5435FD3D.40409@gmail.com>
	<CALqxMTHN4G1HO-7_0Fot943KK-GGOfK9gXDBqaKyyRngiXbuFQ@mail.gmail.com>
Date: Thu, 9 Oct 2014 06:28:19 +0000
Message-ID: <CAAS2fgRmuyK_k4UU+3Lufaq7=j7wR_MXV1PKeb2HqRRa7VX=pQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent
 a txout from being spent until an expiration time
Precedence: list

On Thu, Oct 9, 2014 at 6:14 AM, Adam Back <adam@cypherspace.org> wrote:
> I think you can do everything with the existing script level nlocktime
> in some kind of turing completeness sense (maybe); but there is a
> complexity cost that often you have to resort to extra dependent
> transaction(s) (and work-around malleability until that is fully
> fixed) just to get the effect.

Right, ... moreover, even with all the malleability fixes, they only
work if you refrain from using certain features (e.g. cannot do an
anyone-can-pay) and we cannot be completely sure all accidental
vectors for malleability are gone (we've been unable to construct a
proof that our strengthening of ECDSA turns it into a strong
signature, though it seems likely).

Having the locktime control in a scriptPubKey sidesteps all those
limitations and simplifies protocols (e.g. not requiring some three
step state machine and a bunch of risky validation code to be sure a
refund you receive is actually workable).