Do you think it would be useful to have an inverted version of both CSV and 
CLTV? To verify if an output is spent before a specific time. CLTV and CSV 
could be implemented by taking two stack arguments, an integer for the 
comparison and TRUE/FALSE. 

Now that I think about this more, the problem is that, for example, just having 
a lock time of less than some value doesn't actually mean it has to be spent 
before that script value, so this might not work. Likely any implementations of 
such a feature would have to provide the script execution environment with 
access to information that it doesn't have now, which is what we are trying to 


> On Jun 2, 2015, at 12:16 AM, Mark Friedenbach <> wrote:
> You are correct! I am maintaining a 'checksequenceverify' branch in my git 
> repository as well, an OP_RCLTV using sequence numbers:
> Most of the interesting use cases for relative lock-time require an RCLTV 
> opcode. What is interesting about this architecture is that it possible to 
> cleanly separate the relative lock-time (sequence numbers) from the RCLTV 
> opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like 
> CLTV, the CSV opcode only checks transaction data and requires no contextual 
> knowledge about block headers, a weakness of the other RCLTV proposals that 
> violate the clean separation between libscript and libconsensus. In a similar 
> way, this BIP proposal only touches the transaction validation logic without 
> any impact to script.
> I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY 
> opcode and its enabling applications. But, well, one thing at a time.
>> On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <> 
>> wrote:
>> Hi Mark,
>> Overall, I like this idea in every way except for one: unless I am missing 
>> something, we may still need an OP_RCLTV even with this being implemented. 
>> In use cases such as micropayment channels where the funds are locked up by 
>> multiple parties, the enforcement of the relative locktime can be done by 
>> the first-signing party. So, while your solution would probably work in 
>> cases like this, where multiple signing parties are involved, there may be 
>> other, seen or unforeseen, use cases that require putting the relative 
>> locktime right into the spending contract (the scriptPubKey itself). When 
>> there is only one signer, there's nothing that enforces using an nSequence 
>> and nVersion=2 that would prevent spending the output until a certain time. 
>> I hope this is received as constructive criticism, I do think this is an 
>> innovative idea. In my view, though, it seems to be less fully-featured than 
>> just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously 
>> that it saves transaction space by repurposing unused space, and would 
>> likely work for most cases where an OP_RCLTV would be needed.
>> Best,
>> Stephen
>>> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <> 
>>> wrote:
>>> I have written a reference implementation and BIP draft for a soft-fork 
>>> change to the consensus-enforced behaviour of sequence numbers for the 
>>> purpose of supporting transaction replacement via per-input relative 
>>> lock-times. This proposal was previously discussed on the mailing list in 
>>> the following thread:
>>> In short summary, this proposal seeks to enable safe transaction 
>>> replacement by re-purposing the nSequence field of a transaction input to 
>>> be a consensus-enforced relative lock-time.
>>> The advantages of this approach is that it makes use of the full range of 
>>> the 32-bit sequence number which until now has rarely been used for 
>>> anything other than a boolean control over absolute nLockTime, and it does 
>>> so in a way that is semantically compatible with the originally envisioned 
>>> use of sequence numbers for fast mempool transaction replacement.
>>> The disadvantages are that external constraints often prevent the full 
>>> range of sequence numbers from being used when interpreted as a relative 
>>> lock-time, and re-purposing nSequence as a relative lock-time precludes its 
>>> use in other contexts. The latter point has been partially addressed by 
>>> having the relative lock-time semantics be enforced only if the 
>>> most-significant bit of nSequence is set. This preserves 31 bits for 
>>> alternative use when relative lock-times are not required.
>>> The BIP draft can be found at the following gist:
>>> The reference implementation is available at the following git repository:
>>> I request that the BIP editor please assign a BIP number for this work.
>>> Sincerely,
>>> Mark Friedenbach
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Bitcoin-development mailing list
Bitcoin-development mailing list

Reply via email to