Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

["Jorge Timón" <jtimon@jtimon.cc>]

[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]

Even if it's new and has not received any feedback, I think my solution to
op_maturity is quite clean.
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.
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.
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.
On Apr 27, 2015 9:35 PM, "Peter Todd" <pete@petertodd.org> wrote:

> On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote:
> > On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón <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).
> >
> > 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.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7
>

[-- Attachment #2: Type: text/html, Size: 2796 bytes --]