Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.99 as permitted sender)
	client-ip=62.13.148.99; envelope-from=pete@petertodd.org;
	helo=outmail148099.authsmtp.net; 
Date: Wed, 8 Oct 2014 23:33:31 -0700
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20141009063331.GA16898@muck>
References: <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>
	<CAAS2fgRmuyK_k4UU+3Lufaq7=j7wR_MXV1PKeb2HqRRa7VX=pQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG"
Content-Disposition: inline
In-Reply-To: <CAAS2fgRmuyK_k4UU+3Lufaq7=j7wR_MXV1PKeb2HqRRa7VX=pQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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


--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 09, 2014 at 06:28:19AM +0000, Gregory Maxwell wrote:
> 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.
>=20
> 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).
>=20
> 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).

Speaking of, can anyone think of an example of a complex transaction
use-case that is affected by malleability which can't be fixed by
CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head
trying to think of a good example.

--=20
'peter'[:-1]@petertodd.org
000000000000000012367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622

--OgqxwSJOaUobr8KG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJUNiw3XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMjM2N2QzODVhZDExMzU4YTRhMWVlZTg2Y2Y4ZWJlMDZh
NzZhZGQzNmRmYjQ2MjIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfstcAf/QZsEZFPNbzHU3yyGRcVhK2JF
XOz1Ke43kSz8Q3U9FSn6ZbqKDiameBaVpOjXNyQ3sLtT1V0KhnSf1lSOAA4JaA5B
XE2jjeVw9FYp8RUrHmmgvHEUZUfOrDsQt15s1A24IO+tEZy8KGUnc1zsH+Auo6FS
dO2vM6LVLq6lX0YlBdb7Wmmkm+7pwxaJGgammdl5KNJzSsItmKtGDCd1vpZEC1SM
DeGvOXRQEeFmwqL8aSAUBIkqhoLhk3eOYNQItsDX5kYvriptxEr+VBo2NnS7lAUp
Ow7sFZxG41j2A+kjLTCDORbySDvYWVG61OD9lfDg6dkxqIFRAlEIYx3ObGotxg==
=j8uL
-----END PGP SIGNATURE-----

--OgqxwSJOaUobr8KG--