<p dir="ltr">Even if it's new and has not received any feedback, I think my solution to op_maturity is quite clean. <br>
But anyway, yes, the non-relative cltv is much simpler in design and doesn't have to wait for the other. On the other hand, I would upgrade it to absolute cltv like you suggested and take the current height as a parameter to verifyScript instead of using the nLockTime as reference.<br>
If we know we're going to use it for rcltv/op_maturity, better put add soon rather than later, specially if that will give us a more powerful cltv.<br>
If we don't want that height param, we can leave it out of for op_maturity too, but that's the wingle decision about rcltv/maturity that affects cltv so better solve that first.</p>
<div class="gmail_quote">On Apr 27, 2015 9:35 PM, "Peter Todd" <<a href="mailto:pete@petertodd.org">pete@petertodd.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote:<br>
> On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón <jtimon@jtimon.cc> wrote:<br>
> > And a new softfork rule could enforce that all new CTxIn set nHeight<br>
> > to the correct height in which its corresponding prevout got into the<br>
> > chain.<br>
> > That would remove the need for the TxOutputGetter param in<br>
> > bitcoinconsensus_verify_script, but unfortunately it is not reorg safe<br>
> > (apart from other ugly implementation details).<br>
><br>
> Wait, wait, this can be made reorg-safe and more backards compatible.<br>
> The new validation rule at the tx validation level (currently in<br>
> main::CheckInputs()) would be<br>
<br>
<snip><br>
<br>
So, seems to me that RCLTV opens up a whole rats nest of design<br>
decisions and compromises that CLTV doesn't. Yet CLTV itself is a big<br>
step forward, it's been implemented on Viacoin for the past few months<br>
with no issues found, and has an extremely simple and easy to audit<br>
implementation.<br>
<br>
I think I'm going to argue we implement it as-is in a soft-fork. Pieter<br>
Wuille's been working on a new way to handle soft-fork upgrades in the<br>
block nVersion field, so this would be a good opportunity to add<br>
something simple and well tested, and also make sure the new nVersion<br>
soft-fork mechanism works. Equally, doing both at the same time ensures<br>
we don't burn yet another version bit.<br>
<br>
--<br>
'peter'[:-1]@<a href="http://petertodd.org" target="_blank">petertodd.org</a><br>
00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7<br>
</blockquote></div>