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? On Jul 5, 2015 6:17 PM, "Mark Friedenbach" <[email protected]> wrote:
> 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" <[email protected]> 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 >> [email protected] >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
