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

[Btc Drak <btcdrak@gmail.com>]

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

On Mon, May 4, 2015 at 12:24 PM, Jorge Timón <jtimon@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).

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