Author: Tom Harding 2015-07-05 16:25:17
Published on: 2015-07-05T16:25:17+00:00
A proposal has been made to fix an issue with BIP 68's use of nSequence to specify relative locktime. The problem is that nSequence also conditions the transaction-level locktime, which means a transaction cannot have an effective nLocktime without requiring at least one of its inputs to be mined at least one block or one second ahead of its parent. The proposed solution is to shift the semantics so that nSequence = MAX_INT - 1 specifies 0 relative locktime instead of 1. This change will also preserve the semantics of transactions that have already been created with the specific nSequence value MAX_INT - 1. The discussion also includes a request for an example and use cases where there is a need for an enforced lock time in a transaction with inputs that are not confirmed at the time the lock time expires.
Updated on: 2023-06-10T02:09:25.560691+00:00