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 <>

> 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