Author: Mark Friedenbach 2015-07-05 16:17:19
Published on: 2015-07-05T16:17:19+00:00
Tom Harding, a member of the bitcoin-dev mailing list, discussed the issue of enforced lock time in transactions with inputs that are not confirmed at the time the lock time expires. BIP 68 uses nSequence to specify relative lock time, but it also conditions the transaction-level lock time. This results in preventing a transaction from having an effective nLocktime without requiring at least one of its inputs to be mined at least one block ahead of its parent. To fix this issue, the semantics need to be shifted so that nSequence = MAX_INT - 1 specifies 0 relative lock time instead of 1. This change will preserve the semantics of transactions that have already been created with the specific nSequence value MAX_INT - 1.
Updated on: 2023-06-10T02:09:15.804603+00:00