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

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

Well, apparently the timestamp can be make compatible with Mark's
nSequence-based RCLTV by adding an additional check at the block level
but I was only explaining the concept using heights (which is the most
interesting part IMO).
I'm also not sure I understood the details and I don't want to confuse
people again, so I'll wait for someone else to explain that part.
ACLTV can work with timestamps too unless I'm missing something. It's
just more complexity and I was never convinced that there's enough use
cases relying on timestamps to justify them. But the timestamp
discussion is quite orthogonal to the nSequence-based RCLTV proposal
itself.

On Tue, May 5, 2015 at 2:41 AM, Btc Drak <btcdrak@gmail.com> wrote:
> 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).
>