Published on: 2015-05-13T00:38:44+00:00
In a discussion about the implementation of RCLTV (Relative CheckLockTimeVerify) in Bitcoin, there are different opinions on how to approach the issue. One suggestion is to use negative numbers for the RCLTV instead of the current proposal, as it would not require larger scripts. However, this approach may make handling the year 2038 problem more complex and could lead to ambiguity in the codebase.Luke Dashjr proposed implementing a softfork of RCLTV as a negative CLTV, which would define negative numbers as relative later. This solution is considered straightforward, as all nLockTime values are greater than or equal to any negative number, making CLTV a no-op. The use of negative numbers is not new and should be familiar to developers, especially those with experience in Python. This approach would allow for more flexibility and control in the softforking process.There is also a discussion on whether to use NOPs in Bitcoin's implementation of CheckLockTimeVerify (CLTV) opcode. Some developers argue that using the original unparameterized CLTV version would be better tested and result in a slightly smaller script. On the other hand, adding a parameter to OP_CLTV would make it more flexible and economically feasible. Despite the extra work required to update tests, example code, and the BIP, it is deemed acceptable and necessary for the feature freeze. The use of separate opcodes is also considered, but there are concerns about fitting them into the current CLTV argument structure.Peter Todd suggests adding a parameter to OP_CLTV, which would be the most economical use of NOPs. He believes that the necessary changes can be made in time for the feature freeze and provides a link to the pull request with the suggested changes. Btc Drak agrees with this proposal and emphasizes the importance of making the change before the feature freeze.Another proposal is to use '1' to select absolute mode in OP_CLTV, while all other entries act as NOPs. This would allow for the future implementation of relative CLTV as a soft-fork by using '2' instead of '1'. Rusty Russell suggests an alternative approach, where OP_NOP1 becomes an OP_EXTENSION_PREFIX and the following opcode defines which extended opcode it is. However, this approach is considered complex and difficult to implement.In another email exchange, Peter Todd and Matt Corallo discuss the issue of OP_NOP scarcity in the Bitcoin mempool. Todd suggests that adding a parameter to OP_CLTV would make it more flexible and efficient, despite requiring some extra time and effort to update tests and example code. Corallo raises concerns about complicating the codebase compared to sticking with Script v2.0, but overall, the proposed change is not seen as a big deal.Overall, the discussions revolve around finding the most effective and efficient way to implement RCLTV in Bitcoin. There are different proposals, including using negative numbers, adding parameters to OP_CLTV, or using separate opcodes. The developers acknowledge the potential challenges and complexities involved in making these changes but believe that they are necessary for the improvement of the protocol.
Updated on: 2023-08-01T12:21:21.539533+00:00