Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool only CLTV pull-req²: "I like merging this, but doing both CLTV things in one swoop would be really nice. Certainly if we're gonna use one of the precious few OP_NOPs we have we might as well make it more flexible." I have two lines of thought on this: 1) We're going to end up with a Script v2.0 reasonably soon, probably based on Russel O'Connor and Pieter Wuille's Merkelized Abstract Syntax Tree³ idea. This needs at most a single OP_NOPx to implement and mostly removes the scarcity of upgradable NOP's. 2) Similarly in script v1.0 even if we do use up all ten OP_NOPx's, the logical thing to do is implement an OP_EXTENDED. 3) It's not clear what form a relative CLTV will actually take; the BIP itself proposes a OP_PREVOUT_HEIGHT_VERIFY/OP_PREVOUT_DATA along with OP_ADD, with any opcode accessing non-reorg-safe prevout info being made unavailable until the coinbase maturity period has passed for soft-fork safeness. That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork implemented as follows: 2 OP_CLTV On the bad side it'd be two or three days of work to rewrite all the existing tests and example code and update the BIP, and (slightly) gets us away from the well-tested existing implementation. It also may complicate the codebase compared to sticking with just doing a Script v2.0, with the additional execution environment data required for v2.0 scripts cleanly separated out. But all in all, the above isn't too big of a deal. Interested in your thoughts. 1) https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-98568239 2) https://github.com/bitcoin/bitcoin/pull/5496 3) http://css.csail.mit.edu/6.858/2014/projects/jlrubin-mnaik-nityas.pdf -- 'peter'[:-1]@petertodd.org 00000000000000000908b2eb1cb0660069547abdddad7fa6ad4e743cebe549de