You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers: https://github.com/maaku/bitcoin/tree/checksequenceverify 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: >> >> http://sourceforge.net/p/bitcoin/mailman/message/34146752/ >> >> 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: >> >> https://gist.github.com/maaku/be15629fe64618b14f5a >> >> The reference implementation is available at the following git repository: >> >> https://github.com/maaku/bitcoin/tree/sequencenumbers >> >> I request that the BIP editor please assign a BIP number for this work. >> >> Sincerely, >> Mark Friedenbach >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >