Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

From: Btc Drak <btcdrak@gmail•com>
To: Mark Friedenbach <mark@friedenbach•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
Date: Wed, 16 Sep 2015 23:40:06 +0100	[thread overview]
Message-ID: <CADJgMzsPrg7VhTQC8aCvcQ3yAN8rtt+Qv_yfrCKMqOALpGPVyg@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-tuFtX2t+0FVfkoObw_a9-7j4LwX87YJU1n7adYu=DMdQ@mail.gmail.com>

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

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 <mark@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 <mark@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
>
>

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