* [bitcoin-dev] BIP68: Second-level granularity doesn't make sense
@ 2015-11-24 4:36 Peter Todd
2015-11-24 5:05 ` Btc Drak
0 siblings, 1 reply; 3+ messages in thread
From: Peter Todd @ 2015-11-24 4:36 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2732 bytes --]
BIP68 currently represents by-height locks as a simple 16-bit integer of
the number of blocks - effectively giving a granularity of 600 seconds
on average - but for for by-time locks the representation is a 25-bit
integer with granularity of 1 second. However this granularity doesn't
make sense with BIP113, median time-past as endpoint for lock-time
calcualtions, and poses potential problems for future upgrades.
There's two cases to consider here:
1) No competing transactions
By this we mean that the nSequence field is being used simply to delay
when an output can be spent; there aren't competing transactions trying
to spend that output and thus we're not concerned about one transaction
getting mined before another "out of order". For instance, an 2-factor
escrow service like GreenAddress could use nSequence with
CHECKSEQUENCEVERIFY (CSV) to guarantee that users will eventually get
their funds back after some timeout.
In this use-case exact miner behavior is irrelevant. Equally given the
large tolerances allowed on block times, as well as the poisson
distribution of blocks generated, granularity below an hour or two
doesn't have much practical significance.
2) Competing transactions
Here we are relying on miners prefering lower sequence numbers. For
instance a bidirectional payment channel can decrement nSequence for
each change of direction; BIP68 suggests such a decrement might happen
in increments of one day.
BIP113 makes lock-time calculations use the median time-past as the
threshold for by-time locks. The median time past is calculated by
taking median time of the 11 previous blocks, which means when a miner
creates a block they have absolutely no control over what the median
time-past is; it's purely a function of the block tip they're building
upon.
This means that granularity below a block interval will, on average,
have absolutely no effect at all on what transaction the miner includes
even in the hypothetical case. In practice of course, users will want to
use significantly larger than 1 block interval granularity in protocols.
The downside of BIP68 as written is users of by-height locktimes have 14
bits unused in nSequence, but by-time locktimes have just 5 bits unused.
This presents an awkward situation if we add new meanings to nSequence
if we ever need more than 5 bits. Yet as shown above, the extra
granularity doesn't have a practical benefit.
Recommendation: Change BIP68 to make by-time locks have the same number
of bits as by-height locks, and multiply the by-time lock field by the
block interval.
--
'peter'[:-1]@petertodd.org
000000000000000001a06d85a46abce495fd793f89fe342e6da18b235ade373f
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] BIP68: Second-level granularity doesn't make sense
2015-11-24 4:36 [bitcoin-dev] BIP68: Second-level granularity doesn't make sense Peter Todd
@ 2015-11-24 5:05 ` Btc Drak
2015-11-24 5:58 ` Peter Todd
0 siblings, 1 reply; 3+ messages in thread
From: Btc Drak @ 2015-11-24 5:05 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 981 bytes --]
On Tue, Nov 24, 2015 at 4:36 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> The downside of BIP68 as written is users of by-height locktimes have 14
> bits unused in nSequence, but by-time locktimes have just 5 bits unused.
> This presents an awkward situation if we add new meanings to nSequence
> if we ever need more than 5 bits. Yet as shown above, the extra
> granularity doesn't have a practical benefit.
>
>
> Recommendation: Change BIP68 to make by-time locks have the same number
> of bits as by-height locks, and multiply the by-time lock field by the
> block interval.
>
I think you might be referring to the old specification. I believe this was
brought up before and the specification was changed so the same number of
bits were used for by-time and by-height. Please see
https://github.com/bitcoin/bips/pull/245
However, I am glad you came to the came conclusions independently because
"re-invention" often confirms good ideas :)
[-- Attachment #2: Type: text/html, Size: 1544 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] BIP68: Second-level granularity doesn't make sense
2015-11-24 5:05 ` Btc Drak
@ 2015-11-24 5:58 ` Peter Todd
0 siblings, 0 replies; 3+ messages in thread
From: Peter Todd @ 2015-11-24 5:58 UTC (permalink / raw)
To: Btc Drak; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]
On Tue, Nov 24, 2015 at 05:05:32AM +0000, Btc Drak wrote:
> On Tue, Nov 24, 2015 at 4:36 AM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > The downside of BIP68 as written is users of by-height locktimes have 14
> > bits unused in nSequence, but by-time locktimes have just 5 bits unused.
> > This presents an awkward situation if we add new meanings to nSequence
> > if we ever need more than 5 bits. Yet as shown above, the extra
> > granularity doesn't have a practical benefit.
> >
> >
> > Recommendation: Change BIP68 to make by-time locks have the same number
> > of bits as by-height locks, and multiply the by-time lock field by the
> > block interval.
> >
>
> I think you might be referring to the old specification. I believe this was
> brought up before and the specification was changed so the same number of
> bits were used for by-time and by-height. Please see
> https://github.com/bitcoin/bips/pull/245
>
> However, I am glad you came to the came conclusions independently because
> "re-invention" often confirms good ideas :)
Ha, that's awesome! Looks like we're pretty much on the same page re:
granularity.
--
'peter'[:-1]@petertodd.org
000000000000000003c0cf6b89d2a9b68a8cedbd3935962203c21663925c714b
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-11-24 5:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-24 4:36 [bitcoin-dev] BIP68: Second-level granularity doesn't make sense Peter Todd
2015-11-24 5:05 ` Btc Drak
2015-11-24 5:58 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox