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; 
Date: Mon, 27 Apr 2015 15:35:26 -0400
From: Peter Todd <pete@petertodd.org>
To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@jtimon.cc>,
	Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20150427193526.GH5223@muck>
References: <20141001130826.GM28710@savin.petertodd.org>
	<55075795.20904@bluematt.me>
	<20150421075912.GA25282@savin.petertodd.org>
	<CABm2gDo22grffq4j+Jy_HBD-VrROh32Dbseoa=g-5HXA9Uud1w@mail.gmail.com>
	<CABm2gDovFzpL_7KFqPXxhu4VohRfcE5S_PLAUgjgo_b84GaYeQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ZY5CS28jBCfb727c"
Content-Disposition: inline
In-Reply-To: <CABm2gDovFzpL_7KFqPXxhu4VohRfcE5S_PLAUgjgo_b84GaYeQ@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV
 proposal)
Precedence: list


--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 <jtimon@jtimon.cc> 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

<snip>

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--