MIME-Version: 1.0
In-Reply-To: <CADJgMztaJgUH81Bc1s4P45d2u-35Si7=7rON=UdZn4piycxHpw@mail.gmail.com>
References: <20141001130826.GM28710@savin.petertodd.org>
	<55075795.20904@bluematt.me>
	<20150421075912.GA25282@savin.petertodd.org>
	<5546D653.4070404@bluematt.me>
	<CABm2gDqcD4ENex3LzKfeGqaotoO-XxLHhLzOEPwk92SaiD8snQ@mail.gmail.com>
	<CADJgMztaJgUH81Bc1s4P45d2u-35Si7=7rON=UdZn4piycxHpw@mail.gmail.com>
Date: Tue, 5 May 2015 21:19:00 +0200
Message-ID: <CABm2gDpn-VdNQaMzKSA1tvGhhec3UxdGp-9x-U+ruTWd4ApbiA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Btc Drak <btcdrak@gmail.com>, Mark Friedenbach <mark@friedenbach.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV
	proposal)
Precedence: list

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=C3=B3n <jtimon@jtimon.cc> wrot=
e:
>>
>> 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 =3D 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 fun=
d
> use cases are practical (e.g. spendable on 18th birthday), because the ex=
act
> date a future block will be mined on is unpredictable if it's far enough =
in
> the future (out by days or even weeks).
>