OP_CLTV and OP_CSV are derived from a block header’s time field, a transaction’s locktime field and an input’s sequence field – all of which have 32 bits of precision. From the OP_CLTV opcode
// If we kept to that limit we'd have a year 2038 problem,
// even though the nLockTime field in transactions
// themselves is uint32 which only becomes meaningless
// after the year 2106.
//
// Thus as a special case we tell CScriptNum to accept up
// to 5-byte bignums, which are good until 2**39-1, well
// beyond the 2**32-1 limit of the nLockTime field itself.
This means expanding the precision supported for OP_CLTV/OP_CSV from 40 bits to a higher value would be meaningless unless we expand the precision of the block header’s time field, resulting in a hard fork of the network. I believe anything larger than 33 bits of precision cannot be satisfied on the bitcoin network (even though both OP_CLTV/OP_CSV support up to 40 bits of precision).
Is there a way we could expand the supported precision of this field without modifying the block header’s ntime field and the transaction’s locktime/sequence field?
