Where do we stand now on which sequencenumbers variation to use? We really should make a decision now.
On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So I've created 2 new repositories with changed rules regarding > sequencenumbers: > > https://github.com/maaku/bitcoin/tree/sequencenumbers2 > > This repository inverts (un-inverts?) the sequence number. nSequence=1 > means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1 > second relative lock-height. nSequence>=0x80000000 (most significant bit > set) is not interpreted as a relative lock-time. > > https://github.com/maaku/bitcoin/tree/sequencenumbers3 > > This repository not only inverts the sequence number, but also interprets > it as a fixed-point number. This allows up to 5 year relative lock times > using blocks as units, and saves 12 low-order bits for future use. Or, up > to about 2 year relative lock times using seconds as units, and saves 4 > bits for future use without second-level granularity. More bits could be > recovered from time-based locktimes by choosing a higher granularity (a > soft-fork change if done correctly). > > On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach <m...@friedenbach.org> > wrote: > >> To follow up on this, let's say that you want to be able to have up to 1 >> year relative lock-times. This choice is somewhat arbitrary and what I >> would like some input on, but I'll come back to this point. >> >> * 1 bit is necessary to enable/disable relative lock-time. >> >> * 1 bit is necessary to indicate whether seconds vs blocks as the unit >> of measurement. >> >> * 1 year of time with 1-second granularity requires 25 bits. However >> since blocks occur at approximately 10 minute intervals on average, having >> a relative lock-time significantly less than this interval doesn't make >> much sense. A granularity of 256 seconds would be greater than the Nyquist >> frequency and requires only 17 bits. >> >> * 1 year of blocks with 1-block granularity requires 16 bits. >> >> So time-based relative lock time requires about 19 bits, and block-based >> relative lock-time requires about 18 bits. That leaves 13 or 14 bits for >> other uses. >> >> Assuming a maximum of 1-year relative lock-times. But what is an >> appropriate maximum to choose? The use cases I have considered have only >> had lock times on the order of a few days to a month or so. However I would >> feel uncomfortable going less than a year for a hard maximum, and am having >> trouble thinking of any use case that would require more than a year of >> lock-time. Can anyone else think of a use case that requires >1yr relative >> lock-time? >> >> TL;DR >> >> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <m...@friedenbach.org> >> wrote: >> >>> A power of 2 would be far more efficient here. The key question is how >>> long of a relative block time do you need? Figure out what the maximum >>> should be ( I don't know what that would be, any ideas?) and then see how >>> many bits you have left over. >>> On Aug 23, 2015 7:23 PM, "Jorge Timón" < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev >>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> > Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the >>>> > discussion has any thought been given to represent one block with more >>>> > than one increment? This would leave additional space for future >>>> > signaling, or allow, for example, higher resolution numbers for a >>>> > sharechain commitement. >>>> >>>> No, I don't think anybody thought about this. I just explained this to >>>> Pieter using "for example, 10 instead of 1". >>>> He suggested 600 increments so that it is more similar to timestamps. >>>> _______________________________________________ >>>> 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
