Published on: 2015-07-05T19:57:00+00:00
In July 2015, Tom Harding proposed the idea of allowing an explicit relative locktime of 0 in transactions to prevent accidental finalization of the entire transaction when only intending to exclude a relative locktime on one input. Although Harding initially overlooked that other inputs can independently make the transaction non-final, the proposal still has potential benefits for certain use cases.Harding's proposal suggests shifting the semantics of nSequence in BIP 68, which currently requires at least one input to be mined ahead of its parent for a transaction to have an effective nLocktime. The proposed solution involves using MAX_INT - 1 to specify 0 relative locktime instead of 1. This change would avoid the inversion and put relative locktimes outside the realm of both the MAX_INT and MAX_INT - 1 values. It would also allow applications to avoid accidentally finalizing the whole transaction when they only meant to exclude a relative locktime on one input.Mark Friedenbach suggested that Bitcoin Core post-0.11 switch to using 0 in the sequence number field instead of MAX_INT - 1 for cases where an effective nLocktime is desired without requiring at least one input to be mined ahead of its parent.The proposal aims to fix the issue with BIP 68's use of nSequence to specify relative locktime. Currently, nSequence conditions the transaction-level locktime, making it impossible for a transaction to have an effective nLocktime without at least one input being mined ahead of its parent. Shifting the semantics so that nSequence = MAX_INT - 1 specifies 0 relative locktime instead of 1 would address this problem. The proposed change would also preserve the semantics of transactions already created with the specific nSequence value of MAX_INT - 1. Bitcoin Core may implement this change for cases where the sequence number field is set to 0.Developers on the bitcoin-dev mailing list discussed the issue of locktime in transactions and its impact on fee sniping. They also requested examples and use cases where enforced locktime would be needed in transactions with unconfirmed inputs. The conversation then focused on the use of nSequence to specify relative locktime and the need to shift its semantics to allow for an effective nLocktime without requiring mined inputs. This ongoing discussion demonstrates the efforts of bitcoin developers to enhance the functionality and security of the cryptocurrency's transaction process.Overall, Tom Harding proposed a fix for the issue of enforced lock time in transactions with unconfirmed inputs. The proposal suggests shifting the semantics of nSequence in BIP 68 to specify 0 relative locktime instead of 1. This change would address the problem of a transaction not having an effective nLocktime without requiring at least one input to be mined ahead of its parent. Bitcoin Core may implement this change to improve the transaction process.
Updated on: 2023-08-01T14:14:18.608842+00:00