Release 0.10 of bitcoin added the CHECKLOCKTIMEVERIFY opcode, which checks that the enclosing transaction's absolute lock time requirement is at least the specified value. This opcode is useful and we will be adding in the updated version of script to be deployed with segwit, but adding it pre-segwit with the semantics that bitcoin has prevents using the opcode as a forward block shard identifier.
Additionally, I recall that there were a few things we'd want to do differently with CHECKLOCKTIMEVERIFY, including making minimal encodings a consensus requirement (which was an oversight in bitcoin) and dropping the inputs (which can only be done with a segwit script deployment). These should ideally be fixed now so that the implementation reflects the intended future semantics of the opcode, even if the opcode won't be activated for many releases.
Release 0.10 of bitcoin added the
CHECKLOCKTIMEVERIFY
opcode, which checks that the enclosing transaction's absolute lock time requirement is at least the specified value. This opcode is useful and we will be adding in the updated version of script to be deployed with segwit, but adding it pre-segwit with the semantics that bitcoin has prevents using the opcode as a forward block shard identifier.Additionally, I recall that there were a few things we'd want to do differently with
CHECKLOCKTIMEVERIFY
, including making minimal encodings a consensus requirement (which was an oversight in bitcoin) and dropping the inputs (which can only be done with a segwit script deployment). These should ideally be fixed now so that the implementation reflects the intended future semantics of the opcode, even if the opcode won't be activated for many releases.