MIME-Version: 1.0
In-Reply-To: <5546D653.4070404@bluematt.me>
References: <20141001130826.GM28710@savin.petertodd.org>
	<55075795.20904@bluematt.me>
	<20150421075912.GA25282@savin.petertodd.org>
	<5546D653.4070404@bluematt.me>
Date: Mon, 4 May 2015 13:24:44 +0200
Message-ID: <CABm2gDqcD4ENex3LzKfeGqaotoO-XxLHhLzOEPwk92SaiD8snQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV
	proposal)
Precedence: list

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.