[bitcoin-dev] BIP 68 (Relative Locktime) bug

[bitcoin-dev] BIP 68 (Relative Locktime) bug

[Tom Harding]

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).

Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 1589 bytes --]

Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug

[Pieter Wuille]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

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:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2495 bytes --]

Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug

[Tom Harding]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

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:
>
> 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
>


[-- Attachment #2: Type: text/html, Size: 2592 bytes --]

Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

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:

> 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
>

[-- Attachment #2: Type: text/html, Size: 1677 bytes --]

Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug

[Tom Harding]

[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]

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:
> 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
>
>


[-- Attachment #2: Type: text/html, Size: 3073 bytes --]

Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug

[Tom Harding]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]


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:
>
> 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.


[-- Attachment #2: Type: text/html, Size: 758 bytes --]