Eric, that would be, I think, my sequencenumbers2 branch in which nSequence is an explicit relative lock-time field (unless the most significant bit is set). That has absolutely clear semantics. You should comment on #6312 where this is being discussed. On Wed, Sep 16, 2015 at 7:23 PM, Eric Lombrozo wrote: > I'd rather replace the whole nSequence thing with an explicit relative > locktime with clear semantics...but I'm not going to fight this one too > much. > > > On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> 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 >>> 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 >>> > 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 >>>>>> 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 >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >