public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Alex Morcos <morcos@gmail.com>
To: Adam Back <adam@cypherspace.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Date: Thu, 15 Oct 2015 12:41:57 -0400	[thread overview]
Message-ID: <CAPWm=eVRespS+FDm4zpnBSi7-UWBV7pE1x+=FubADQfVwEK9RA@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTEG-LVRA9VtYOzNMBUCK_M78Fx6ivVY9NZ8B2rfom5oKA@mail.gmail.com>

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

Adam,

The remaining 14 bits can be used to soft fork in finer granularity in the
future.

Alex


On Thu, Oct 15, 2015 at 12:37 PM, Adam Back <adam@cypherspace.org> wrote:

> Does that pre-judge that block interval would never change from
> 10mins?  Eg say with IBLT or fountain codes etc and security arguments
> for the current limitations of them are found, such that orphan rates
> can remain low in a decentralised way with 1min blocks, then the
> locktime granularity would be coarse relative to the block interval
> (with 512s locktime granularity.
>
> Adam
>
> On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Alex,
> >
> > I am sorry for not communicating more clearly. Mark and I discussed your
> > concerns from the last meeting and he made the change. The BIP text still
> > needs to be updated, but the discussed change was added to the PR, albeit
> > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits
> with
> > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and
> > SEQUENCE_LOCKTIME_GRANULARITY in the PR
> > https://github.com/bitcoin/bitcoin/pull/6312.
> >
> >     /* If CTxIn::nSequence encodes a relative lock-time, this mask is
> >      * applied to extract that lock-time from the sequence field. */
> >     static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
> >
> >     /* In order to use the same number of bits to encode roughly the
> >      * same wall-clock duration, and because blocks are naturally
> >      * limited to occur every 600s on average, the minimum granularity
> >      * for time-based relative lock-time is fixed at 512 seconds.
> >      * Converting from CTxIn::nSequence to seconds is performed by
> >      * multiplying by 512 = 2^9, or equivalently shifting up by
> >      * 9 bits. */
> >     static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
> >
> > I am also much happier with this last tightening up of the specification
> > because it removes ambiguity. 512s granularity makes sense within the
> > context of the 10 minute block target.
> >
> > Thank you for spending so much time carefully considering this BIP and
> > reference implementation and please let me know if there there are any
> > remaining nits so we can get those addressed.
> >
> >
> >
> >
> >
> > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Mark,
> >>
> >> You seemed interested in changing BIP 68 to use 16 bits for sequence
> >> number in both the block and time versions, making time based sequence
> >> numbers have a resolution of 512 seconds.
> >>
> >> I'm in favor of this approach because it leaves aside 14 bits for
> further
> >> soft forks within the semantics of BIP 68.
> >>
> >> It would be nice to know if you're planning this change, and perhaps
> >> people can hold off on review until things are finalized.
> >>
> >> I'd cast my "vote" against BIP 68 without this change, but am also open
> to
> >> being convinced otherwise.
> >>
> >> What are other peoples opinions on this?
> >>
> >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>>
> >>> Peter Todd <pete@petertodd.org> writes:
> >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >>> >> Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> >>> >> writes:
> >>> >> > However I don't think we've done a good job showing why we need to
> >>> >> > implement this feature via nSequence.
> >>> >>
> >>> >> It could be implemented in other ways, but nSequence is the neatest
> >>> >> and
> >>> >> most straightforward I've seen.
> >>> >>
> >>> >> - I'm not aware of any other (even vague) proposal for its use?
> >>> >> Enlighten?
> >>> >
> >>> > There's three that immediately come to mind:
> >>> >
> >>> > Gregory Maxwell has proposed it as a way of discouraging miners from
> >>> > reorging chains, by including some of the low-order bits of a
> previous
> >>> > block header in nSequence.
> >>> >
> >>> > A few people have proposed implementing proof-of-stake blocksize
> voting
> >>> > with nSequence.
> >>>
> >>> Excellent, thanks!  It's good to have such ideas as a compass.  PoS
> >>> voting seems like it won't be a problem in 5 bits.
> >>>
> >>> The "prevbits" idea would want more bits; naively 64 would be good, but
> >>> I think there are some tricks we can use to make 32 work OK.  We would
> >>> have to then split between nLocktime (if available) and multiple
> >>> nSequence fields, and it would weaken it for some txs.
> >>>
> >>> There is one easy solution: change the BIP wording from:
> >>>
> >>> -For transactions with an nVersion of 2 or greater,
> >>> +For transactions with an nVersion of 2,
> >>>
> >>> And on every tx bump, we decide whether to keep this scheme (mempool
> >>> would enforce it always).
> >>>
> >>> Cheers,
> >>> Rusty.
> >>> _______________________________________________
> >>> 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
> >>
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

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

  reply	other threads:[~2015-10-15 16:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-03 14:30 [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change Peter Todd
2015-10-03 18:49 ` jl2012
2015-10-04  8:35 ` Anthony Towns
2015-10-04 12:04   ` s7r
2015-10-05 22:03     ` Alex Morcos
2015-10-06  0:19       ` Mark Friedenbach
2015-10-06 11:09         ` Peter Todd
2015-10-06  0:28 ` Btc Drak
2015-10-06  1:58 ` Rusty Russell
2015-10-08 17:41   ` Peter Todd
2015-10-09  1:38     ` Rusty Russell
2015-10-15 13:47       ` Alex Morcos
2015-10-15 16:27         ` Btc Drak
2015-10-15 16:37           ` Adam Back
2015-10-15 16:41             ` Alex Morcos [this message]
2015-10-15 18:31             ` Mark Friedenbach
2015-10-15 23:18           ` Rusty Russell
2015-10-16  1:26             ` Rusty Russell
2015-10-19 10:43               ` Jorge Timón
2015-10-06 20:00 ` Joseph Poon
2015-10-08 17:43 ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPWm=eVRespS+FDm4zpnBSi7-UWBV7pE1x+=FubADQfVwEK9RA@mail.gmail.com' \
    --to=morcos@gmail.com \
    --cc=adam@cypherspace.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox