Published on: 2015-11-27T10:14:10+00:00
In an email thread on the bitcoin-dev mailing list, Mark Friedenbach expressed his objection to the use of nSequence in Bitcoin's implementation. He suggested renaming it to nMaturity, a suggestion he had previously made before the implementation began. However, he acknowledged that it was now too late to make such changes without disrupting the implementation. The discussion focuses on the relative locktime (or minimum age) and the nSequence field in transactions, which currently plays a combined role. The lack of a dedicated field for the purpose of relative locktime is considered unfortunate as it requires repurposing unused bits in the txin. However, there may be ways around this issue using segwit.One suggestion is to add an extra input vector to the prunable extra data that comprises the witness. Witness structures can provide additional data that is used in transaction validation but does not contribute to the tx hash. Adding extra prunable signed data fields to transactions may ultimately remove scarcity of tx data that can be repurposed via soft forks. The nSequence field could be turned into a dedicated min age/rlt field to simplify semantics and avoid ugliness in trying to reclaim unused bits.The article discusses the limited availability of single-byte opcodes left, with only ten single-byte OP_NOPx opcodes defined. Additionally, there are 66 single-byte values that are currently reserved. The author argues that it seems trivial to him to add a comment in script.h, which would neither slow compilation nor confuse anyone but could lead the curious to explore history and expand their knowledge. The article also talks about the name OP_CHECKSEQUENCEVERIFY, which should not be changed. The author explains that each person has a single best reason not to change it, and finding other reasons suggests that one's top reason is not good enough. Moreover, the article highlights that the same goes for changing it. In any case, it is 178 (0xb2), and app developers can call it whatever they want.Eric Lombrozo, a developer, believes that relative timelock is the most important exposed functionality intended for app developers. He also agrees with Mark and Matt that the relative locktime feature is not in the CSV opcode but in the nSequence calculation. Rusty, who developed scripts using CSV, supports keeping CSV as it is.In a bitcoin-dev email thread, Eric Lombrozo proposed that the full opcode name for CHECKRELATIVELOCKTIMEVERIFY should be abbreviated. He suggested using both CLTV and CRLTV for abbreviation, however, these abbreviations are hard to distinguish from each other. Peter Todd suggested using the abbreviation AGEVERIFY instead, which is short and sweet.The discussion in the bitcoin-dev mailing list revolves around the naming of the opcode for BIP112, which verifies the time/maturity of transaction inputs relative to their inclusion in a block. The original name suggested was CHECKSEQUENCEVERIFY (CSV), but some members propose that it should be renamed to reflect its actual use case rather than focusing on the bitcoin internals. Eric Lombrozo argues that app developers need a clear interface to develop apps and that relative timelock is the critical exposed functionality intended here. He suggests calling the opcode RCHECKLOCKTIMEVERIFY to communicate fairly directly to developers and protocol designers the semantics they actually care about and also make clear the relationship between absolute and relative timelock. Mark Friedenbach, who originated the name CHECKSEQUENCEVERIFY, explains that the names are purposefully chosen to illustrate what they do and that the semantics are not limited to relative lock-time/maturity only. However, many members agree with Eric Lombrozo that the opcode should be renamed to reflect its actual use case. Suggestions include CHECKMATURITYVERIFY, RELATIVELOCKTIMEVERIFY, RCHECKLOCKTIMEVERIFY, and RCLTV.The discussion is about the naming convention of an opcode related to timelock functionality in the Bitcoin system. Eric Lombrozo suggests that the naming convention should be CHECKVERIFY, and the full opcode name should be CHECKRELATIVELOCKTIMEVERIFY, but it is too long and should be abbreviated. He also thinks that timelock is more relevant from an application developer standpoint than maturity because it controls when funds can be moved. Eric believes that RCLTV or RCHECKLOCKTIMEVERIFY is a better choice for abbreviation as we already have CLTV, which makes the relationship between the two more explicit. He further adds about the possibility of adding opcodes with segregated witness that push values onto the stack. Jorge Timón also agrees with Eric's suggestion and proposes CMV instead of the check_x_verify naming pattern.The debate over the naming of opcode CHECKSEQUENCEVERIFY (OP_CSV) in BIP112 continues. While the name was purposefully chosen to illustrate its function, some argue that it is too broad and limits the use of nSequence bits for future applications.
Updated on: 2023-08-01T16:54:45.616066+00:00