BIP 68 (Relative Locktime) bug
7 messages, 5 Jul 2015. Started by Tom Harding.
Tom Harding (4), Mark F (2), Pieter Wuille
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).
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:
Quoted text (19 lines)
> 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 >
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" <mark@friedenbach•org> wrote:
Quoted text (31 lines)
> 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 > >
Since you're removing a working capability, you should be the one to prove it is unneeded.
But the simple example is the case where the input is also locked.
On 7/5/2015 9:17 AM, Mark Friedenbach wrote:
Quoted text (29 lines)
> > 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 > <mailto: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 > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Note that you can put 0 in the sequence number field and it would work just as expected under the old rules. I will perhaps suggest instead that Bitcoin Core post-0.11 switch to doing this instead for that case.
On Sun, Jul 5, 2015 at 8:00 AM, Tom Harding <tomh@thinlink•com> wrote:
Quoted text (19 lines)
> 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 >
Or you could flip the definition of your activation bit. That would avoid the inversion and put relative locktimes outside the realm of both the MAX_INT and MAX_INT - 1 values.
It would also allow an explicit relative locktime of 0, which would help applications avoid accidentally finalizing the whole transaction when they only meant to not impose a relative locktime on one input.
On 7/5/2015 10:07 AM, Mark Friedenbach wrote:
Quoted text (29 lines)
> Note that you can put 0 in the sequence number field and it would work > just as expected under the old rules. I will perhaps suggest instead > that Bitcoin Core post-0.11 switch to doing this instead for that case. > > On Sun, Jul 5, 2015 at 8:00 AM, Tom Harding <tomh@thinlink•com > <mailto: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 > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
Never mind that last bit. I overlooked that the other inputs can independently make the tx non-final.
On 7/5/2015 12:50 PM, Tom Harding wrote:
Quoted text (4 lines)
> > It would also allow an explicit relative locktime of 0, which would > help applications avoid accidentally finalizing the whole transaction > when they only meant to not impose a relative locktime on one input.