Published on: 2015-06-17T01:20:25+00:00
Mark Friedenbach has proposed a soft-fork change to the consensus-enforced behavior of sequence numbers in Bitcoin. The purpose of this change is to enable safe transaction replacement via per-input relative lock-times. Friedenbach has requested the assignment of a BIP number for this work, and the BIP draft and reference implementation are available on GitHub.The proposed change involves repurposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time. This would allow for the use of the full range of the 32-bit sequence number, which has rarely been used for anything other than boolean control over absolute nLockTime. The goal is to make use of the sequence numbers in a way that is compatible with the originally envisioned use for fast mempool transaction replacement.However, there are some disadvantages to this approach. External constraints often prevent the full range of sequence numbers from being used when interpreted as a relative lock-time, and repurposing nSequence as a relative lock-time precludes its use in other contexts. To address this, the proposal suggests enforcing the relative lock-time semantics only if the most significant bit of nSequence is set, leaving 31 bits for alternative use when relative lock-times are not required.In the email conversation, there is discussion about the possibility of implementing a "not after" feature in Bitcoin script, which would make a script that was once valid later invalid. However, it is noted that this may not be compatible with the current model of reprocessing transactions in later blocks if the block they were first in gets reorganized. One suggestion is to make it the previous holder's responsibility to spend a "not before" back to themselves.There is also discussion about the need for an OP_RCLTV (Relative CheckLockTimeVerify) opcode, even with Friedenbach's proposed implementation. While the proposed solution may work in cases where multiple signing parties are involved, there may be other use cases that require putting the relative lock-time right into the spending contract. It is suggested that repurposing an OP_NOP opcode to create OP_RCLTV could be a more fully-featured solution.Overall, Friedenbach's proposal aims to enable safe transaction replacement by repurposing sequence numbers as relative lock-times. While there are some disadvantages and potential issues raised in the discussion, the proposal is viewed as innovative and has generated interest among the Bitcoin community. Mark Friedenbach has requested the BIP editor to assign a BIP number for his work to further advance this proposal.
Updated on: 2023-08-01T13:02:08.050466+00:00