* [bitcoin-dev] BIP 68 (Relative Locktime) bug
@ 2015-07-05 15:00 Tom Harding
2015-07-05 16:17 ` Mark Friedenbach
2015-07-05 17:07 ` Mark Friedenbach
0 siblings, 2 replies; 7+ messages in thread
From: Tom Harding @ 2015-07-05 15:00 UTC (permalink / raw)
To: bitcoin-dev
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).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug
2015-07-05 15:00 [bitcoin-dev] BIP 68 (Relative Locktime) bug Tom Harding
@ 2015-07-05 16:17 ` Mark Friedenbach
2015-07-05 16:21 ` Pieter Wuille
2015-07-05 16:25 ` Tom Harding
2015-07-05 17:07 ` Mark Friedenbach
1 sibling, 2 replies; 7+ messages in thread
From: Mark Friedenbach @ 2015-07-05 16:17 UTC (permalink / raw)
To: Tom Harding; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug
2015-07-05 16:17 ` Mark Friedenbach
@ 2015-07-05 16:21 ` Pieter Wuille
2015-07-05 16:25 ` Tom Harding
1 sibling, 0 replies; 7+ messages in thread
From: Pieter Wuille @ 2015-07-05 16:21 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug
2015-07-05 16:17 ` Mark Friedenbach
2015-07-05 16:21 ` Pieter Wuille
@ 2015-07-05 16:25 ` Tom Harding
1 sibling, 0 replies; 7+ messages in thread
From: Tom Harding @ 2015-07-05 16:25 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug
2015-07-05 15:00 [bitcoin-dev] BIP 68 (Relative Locktime) bug Tom Harding
2015-07-05 16:17 ` Mark Friedenbach
@ 2015-07-05 17:07 ` Mark Friedenbach
2015-07-05 19:50 ` Tom Harding
1 sibling, 1 reply; 7+ messages in thread
From: Mark Friedenbach @ 2015-07-05 17:07 UTC (permalink / raw)
To: Tom Harding; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug
2015-07-05 17:07 ` Mark Friedenbach
@ 2015-07-05 19:50 ` Tom Harding
2015-07-05 19:57 ` Tom Harding
0 siblings, 1 reply; 7+ messages in thread
From: Tom Harding @ 2015-07-05 19:50 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BIP 68 (Relative Locktime) bug
2015-07-05 19:50 ` Tom Harding
@ 2015-07-05 19:57 ` Tom Harding
0 siblings, 0 replies; 7+ messages in thread
From: Tom Harding @ 2015-07-05 19:57 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-07-05 19:56 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-05 15:00 [bitcoin-dev] BIP 68 (Relative Locktime) bug Tom Harding
2015-07-05 16:17 ` Mark Friedenbach
2015-07-05 16:21 ` Pieter Wuille
2015-07-05 16:25 ` Tom Harding
2015-07-05 17:07 ` Mark Friedenbach
2015-07-05 19:50 ` Tom Harding
2015-07-05 19:57 ` Tom Harding
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox