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

[Btc Drak]

On Mon, May 4, 2015 at 12:24 PM, Jorge Timón <jtimon at jtimon.cc> wrote:

> What I was describing was an attempt to fix a similar proposal by Mark
> Friedenbach, but it didn't needed fixing: I was simply
> misunderstanding it.
> Mark's RCLTV is completely reorg safe, so there's no need for the 100
> block restriction. It also keeps the script validation independent
> from the utxo.
> Here's is how it works:
>
> The operator takes a relative_height parameter and it checks that the
> nSequence of the input is lower than that parameter.
>
> Additionally, a new check at the transaction level:
>
> for (unsigned int i = 0; i < tx.vin.size(); i++) {
> // ...
>             if (coins->nHeight + tx.vin[i].nSequence < nSpendHeight)
>                 return state.Invalid(false, REJECT_INVALID,
> "bad-txns-non-final-input");
> // ...
> }
>
> Well, this is assuming that we're only using it with heights and not
> timestamps.
> Mark, feel free to elaborate further.


Does dropping timestamp refer just to RCLTV or absolutely CLTV also? For
absolute CLTV I think it's important to have timestamps so that trust fund
use cases are practical (e.g. spendable on 18th birthday), because the
exact date a future block will be mined on is unpredictable if it's far
enough in the future (out by days or even weeks).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150505/5cc624fb/attachment.html>