I would say yes. Just putting a locktime in transaction may help against fee sniping, even in transactions that are allowed to be mined at the same time as some of their dependencies?
Can you construct an example? Are there 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?
On Jul 5, 2015 8:00 AM, "Tom Harding" <tomh@thinlink.com> wrote: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
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev