From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ymooi-0002Ed-3q for bitcoin-development@lists.sourceforge.net; Mon, 27 Apr 2015 19:35:44 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.77 as permitted sender) client-ip=62.13.149.77; envelope-from=pete@petertodd.org; helo=outmail149077.authsmtp.com; Received: from outmail149077.authsmtp.com ([62.13.149.77]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Ymooe-0000CL-Lj for bitcoin-development@lists.sourceforge.net; Mon, 27 Apr 2015 19:35:44 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t3RJZWPG009672; Mon, 27 Apr 2015 20:35:32 +0100 (BST) Received: from muck (rrcs-23-246-65-155.nyc.biz.rr.com [23.246.65.155]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t3RJZQtO075155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 27 Apr 2015 20:35:30 +0100 (BST) Date: Mon, 27 Apr 2015 15:35:26 -0400 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= , Pieter Wuille Message-ID: <20150427193526.GH5223@muck> References: <20141001130826.GM28710@savin.petertodd.org> <55075795.20904@bluematt.me> <20150421075912.GA25282@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZY5CS28jBCfb727c" Content-Disposition: inline In-Reply-To: X-Server-Quench: 90eb080c-ed14-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdAUUGUUGAgsB AmMbWVReU1h7WmI7 aQlPbwFbfExLQQRv VVdMSlVNFUssAn57 bH9aLRl1cgRDfTBx Y0NiWz5SXBEodU59 EVMBQWwCeGZhPWQC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4xEzo1 WxEcEH0EPWAuZAEU BD8aC3sxImsrE2sD eRs+UElQGDsuNG8W B1tKGChCLl1ALwAA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 23.246.65.155/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. -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: 1Ymooe-0000CL-Lj Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) 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: Mon, 27 Apr 2015 19:35:44 -0000 --ZY5CS28jBCfb727c Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Tim=F3n wrote: > On Sun, Apr 26, 2015 at 1:35 PM, Jorge Tim=F3n wrote: > > And a new softfork rule could enforce that all new CTxIn set nHeight > > to the correct height in which its corresponding prevout got into the > > chain. > > That would remove the need for the TxOutputGetter param in > > bitcoinconsensus_verify_script, but unfortunately it is not reorg safe > > (apart from other ugly implementation details). >=20 > Wait, wait, this can be made reorg-safe and more backards compatible. > The new validation rule at the tx validation level (currently in > main::CheckInputs()) would be So, seems to me that RCLTV opens up a whole rats nest of design decisions and compromises that CLTV doesn't. Yet CLTV itself is a big step forward, it's been implemented on Viacoin for the past few months with no issues found, and has an extremely simple and easy to audit implementation. I think I'm going to argue we implement it as-is in a soft-fork. Pieter Wuille's been working on a new way to handle soft-fork upgrades in the block nVersion field, so this would be a good opportunity to add something simple and well tested, and also make sure the new nVersion soft-fork mechanism works. Equally, doing both at the same time ensures we don't burn yet another version bit. --=20 'peter'[:-1]@petertodd.org 00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 --ZY5CS28jBCfb727c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVPo97XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwZTc5ODBhYWI5YzA5NmM0NmU3ZjM0YzQzYTY2MWM1Y2Iy ZWE3MTUyNWViYjhhZjcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyIhwf+O1VHfI4MlkQFKCeo5fOUMi4H cHaiOCu9Zppz03wc63xBMZ4C1Vtoi9WwZXgGBt7s+1M5e+LJnjFEGrPFF54HeQ3U P/mHqSOQLfQd1ucaCvCSvyxeZ95W+7NJj8KO6L+8uKPiVPdooRzy97QmZe8UYB4d DCig0xnuI07b0v13DKz1o1WXQVPzzUdC+a0MnAKws/+Sdin9dpRAIAUlukyCCye9 ZuQDg7D5djCYlNLJKtZlUMkg5LymiC1v5lLTXeAfZNAWKKV4b6WtduRJV6xQSPY1 bN9lEzGTP3+aqcu+FBb0tqRwoecua5k76TLejFMsXnrDbVp90UDnYnyQOJlW4Q== =YIy0 -----END PGP SIGNATURE----- --ZY5CS28jBCfb727c--