On Mon, May 4, 2015 at 12:24 PM, Jorge Timón <jti...@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).
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
Bitcoin-development mailing list

Reply via email to