BIP 68 uses nSequence to specify relative locktime, but nSequence also continues to condition the transaction-level locktime.
This dual effect will prevent a transaction from having an effective nLocktime without also requiring at least one of its inputs to be mined at least one block (or one second) ahead of its parent. The fix is to shift the semantics so that nSequence = MAX_INT - 1 specifies 0 relative locktime, rather than 1. This change will also preserve the semantics of transactions that have already been created with the specific nSequence value MAX_INT - 1 (for example all transactions created by the bitcoin core wallet starting in 0.11). _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
