Author: Btc Drak 2015-05-12 19:30:35
Published on: 2015-05-12T19:30:35+00:00
There is a discussion about the use of NOPs in Bitcoin's implementation of CheckLockTimeVerify (CLTV) opcode. Some developers argue that since there isn't actually scarcity of NOPs, it makes sense to choose the original unparameterized CLTV version #6124 which has been better tested and results in a slightly smaller script. On the other hand, adding a parameter to OP_CLTV makes it more flexible and is the most economic use of precious NOPs. The extra time required to make this change is deemed acceptable and it would be good to make this change to the PR in time for the feature freeze. However, there are concerns about whether to use #5496 or #6124 and it would be nice to decide and stop blocking this. It is also mentioned that we can always use the same trick with the last opcode to get 2^64 brand new opcodes. Some developers suggest that implementing a future relative CLTV as a future soft-fork could be a solution. Despite the extra work required to rewrite all the existing tests and example code and update the BIP, it is not too big of a deal.
Updated on: 2023-06-09T19:28:31.570056+00:00