📅 Original date posted:2015-09-17
📝 Original message: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 <elombrozo at gmail.com> 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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org> wrote:
>>>>>
>>>>>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev
>>>>>> <bitcoin-dev at 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 at lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>> ------------------------------
>>
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150917/2a787e07/attachment-0001.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 17:40:41
in reply to nevent1q…k0rk
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 17:40:41Event JSON
{
"id": "cd15cda44527186b8549bb669163ba458ed6b46d1e4d56a0ff6ade52872a9982",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686159641,
"kind": 1,
"tags": [
[
"e",
"5fe477206535624090ccd89b16e7648847cf7e7a4f6f91630a129cd4e6eed9a8",
"",
"root"
],
[
"e",
"5f0e3f3b604046d9093baa08f859cee1ec2ec8c4283d877b6a13a66345c4e2aa",
"",
"reply"
],
[
"p",
"e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f"
]
],
"content": "📅 Original date posted:2015-09-17\n📝 Original message:Eric, that would be, I think, my sequencenumbers2 branch in which nSequence\nis an explicit relative lock-time field (unless the most significant bit is\nset). That has absolutely clear semantics. You should comment on #6312\nwhere this is being discussed.\n\nOn Wed, Sep 16, 2015 at 7:23 PM, Eric Lombrozo \u003celombrozo at gmail.com\u003e wrote:\n\n\u003e I'd rather replace the whole nSequence thing with an explicit relative\n\u003e locktime with clear semantics...but I'm not going to fight this one too\n\u003e much.\n\u003e\n\u003e\n\u003e On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Where do we stand now on which sequencenumbers variation to use? We\n\u003e\u003e really should make a decision now.\n\u003e\u003e\n\u003e\u003e On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e So I've created 2 new repositories with changed rules regarding\n\u003e\u003e\u003e sequencenumbers:\n\u003e\u003e\u003e\n\u003e\u003e\u003e https://github.com/maaku/bitcoin/tree/sequencenumbers2\n\u003e\u003e\u003e\n\u003e\u003e\u003e This repository inverts (un-inverts?) the sequence number. nSequence=1\n\u003e\u003e\u003e means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1\n\u003e\u003e\u003e second relative lock-height. nSequence\u003e=0x80000000 (most significant bit\n\u003e\u003e\u003e set) is not interpreted as a relative lock-time.\n\u003e\u003e\u003e\n\u003e\u003e\u003e https://github.com/maaku/bitcoin/tree/sequencenumbers3\n\u003e\u003e\u003e\n\u003e\u003e\u003e This repository not only inverts the sequence number, but also\n\u003e\u003e\u003e interprets it as a fixed-point number. This allows up to 5 year relative\n\u003e\u003e\u003e lock times using blocks as units, and saves 12 low-order bits for future\n\u003e\u003e\u003e use. Or, up to about 2 year relative lock times using seconds as units, and\n\u003e\u003e\u003e saves 4 bits for future use without second-level granularity. More bits\n\u003e\u003e\u003e could be recovered from time-based locktimes by choosing a higher\n\u003e\u003e\u003e granularity (a soft-fork change if done correctly).\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\n\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e To follow up on this, let's say that you want to be able to have up to\n\u003e\u003e\u003e\u003e 1 year relative lock-times. This choice is somewhat arbitrary and what I\n\u003e\u003e\u003e\u003e would like some input on, but I'll come back to this point.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e * 1 bit is necessary to enable/disable relative lock-time.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e * 1 bit is necessary to indicate whether seconds vs blocks as the unit\n\u003e\u003e\u003e\u003e of measurement.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e * 1 year of time with 1-second granularity requires 25 bits. However\n\u003e\u003e\u003e\u003e since blocks occur at approximately 10 minute intervals on average, having\n\u003e\u003e\u003e\u003e a relative lock-time significantly less than this interval doesn't make\n\u003e\u003e\u003e\u003e much sense. A granularity of 256 seconds would be greater than the Nyquist\n\u003e\u003e\u003e\u003e frequency and requires only 17 bits.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e * 1 year of blocks with 1-block granularity requires 16 bits.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e So time-based relative lock time requires about 19 bits, and\n\u003e\u003e\u003e\u003e block-based relative lock-time requires about 18 bits. That leaves 13 or 14\n\u003e\u003e\u003e\u003e bits for other uses.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Assuming a maximum of 1-year relative lock-times. But what is an\n\u003e\u003e\u003e\u003e appropriate maximum to choose? The use cases I have considered have only\n\u003e\u003e\u003e\u003e had lock times on the order of a few days to a month or so. However I would\n\u003e\u003e\u003e\u003e feel uncomfortable going less than a year for a hard maximum, and am having\n\u003e\u003e\u003e\u003e trouble thinking of any use case that would require more than a year of\n\u003e\u003e\u003e\u003e lock-time. Can anyone else think of a use case that requires \u003e1yr relative\n\u003e\u003e\u003e\u003e lock-time?\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e TL;DR\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach \u003cmark at friedenbach.org\n\u003e\u003e\u003e\u003e \u003e wrote:\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e A power of 2 would be far more efficient here. The key question is how\n\u003e\u003e\u003e\u003e\u003e long of a relative block time do you need? Figure out what the maximum\n\u003e\u003e\u003e\u003e\u003e should be ( I don't know what that would be, any ideas?) and then see how\n\u003e\u003e\u003e\u003e\u003e many bits you have left over.\n\u003e\u003e\u003e\u003e\u003e On Aug 23, 2015 7:23 PM, \"Jorge Timón\" \u003c\n\u003e\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e\u003e \u003e Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the\n\u003e\u003e\u003e\u003e\u003e\u003e \u003e discussion has any thought been given to represent one block with\n\u003e\u003e\u003e\u003e\u003e\u003e more\n\u003e\u003e\u003e\u003e\u003e\u003e \u003e than one increment? This would leave additional space for future\n\u003e\u003e\u003e\u003e\u003e\u003e \u003e signaling, or allow, for example, higher resolution numbers for a\n\u003e\u003e\u003e\u003e\u003e\u003e \u003e sharechain commitement.\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\u003e No, I don't think anybody thought about this. I just explained this to\n\u003e\u003e\u003e\u003e\u003e\u003e Pieter using \"for example, 10 instead of 1\".\n\u003e\u003e\u003e\u003e\u003e\u003e He suggested 600 increments so that it is more similar to timestamps.\n\u003e\u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e ------------------------------\n\u003e\u003e\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e --\n\u003e Sent from my Android device with K-9 Mail. Please excuse my brevity.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150917/2a787e07/attachment-0001.html\u003e",
"sig": "7e85a3f84d69b81752ebe1ff03a57cb9fca87110dad053ef714583f508ec525a7387cf32f15e06d678fcc5aa6e82b4b43914b4bc0e153b4234a800e60ee36dec"
}