From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xc7IL-0005Mx-NL for bitcoin-development@lists.sourceforge.net; Thu, 09 Oct 2014 06:33:49 +0000 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; Received: from outmail148099.authsmtp.net ([62.13.148.99]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Xc7IK-0004r9-BG for bitcoin-development@lists.sourceforge.net; Thu, 09 Oct 2014 06:33:49 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s996XavO049540; Thu, 9 Oct 2014 07:33:36 +0100 (BST) Received: from muck (199-36-244-16.mccarran.com [199.36.244.16] (may be forged)) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s996XVIL014239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 9 Oct 2014 07:33:34 +0100 (BST) Date: Wed, 8 Oct 2014 23:33:31 -0700 From: Peter Todd To: Gregory Maxwell Message-ID: <20141009063331.GA16898@muck> References: <20141004003850.GA23202@muck> <5435FD3D.40409@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: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 325bbab2-4f7e-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgsUF1YAAgsB AmIbW1NeU157WmY7 agNYcwZbfEhKWxtr VldMSlVNFUsrCBUH bnhnLhlzcwdFcTBx YUBmWj5YXkEoJxcv QFNQQ2pTeGZhPWQC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA44NB8E DxwYFDszKAUuZwgY DDgBAX0gPWM8DGgI EHUQERdQCwUfFABY AyMFCWdFN14cW2Il FwRfFUQTETtSCTxE Dxs0agJOHj1WEiNe TEZVUxAVAj9EVy8A VDdYX0UA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 199.36.244.16/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [62.13.148.99 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Xc7IK-0004r9-BG Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 06:33:49 -0000 --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 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--