📅 Original date posted:2015-09-16
📝 Original message: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/20150916/6256d65f/attachment.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:40:41
in reply to nevent1q…n5w9
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:40:41Event JSON
{
"id": "5f0e3f3b604046d9093baa08f859cee1ec2ec8c4283d877b6a13a66345c4e2aa",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159641,
"kind": 1,
"tags": [
[
"e",
"5fe477206535624090ccd89b16e7648847cf7e7a4f6f91630a129cd4e6eed9a8",
"",
"root"
],
[
"e",
"6f7642b029888cdeb53a7716f6e2e49c66a77501c81f10c268ce4f3d1fc876fd",
"",
"reply"
],
[
"p",
"fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83"
]
],
"content": "📅 Original date posted:2015-09-16\n📝 Original message: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.\n\nOn September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eWhere do we stand now on which sequencenumbers variation to use? We\n\u003ereally\n\u003eshould make a decision now.\n\u003e\n\u003eOn Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev \u003c\n\u003ebitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e So I've created 2 new repositories with changed rules regarding\n\u003e\u003e sequencenumbers:\n\u003e\u003e\n\u003e\u003e https://github.com/maaku/bitcoin/tree/sequencenumbers2\n\u003e\u003e\n\u003e\u003e This repository inverts (un-inverts?) the sequence number.\n\u003enSequence=1\n\u003e\u003e means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD\n\u003emeans 1\n\u003e\u003e second relative lock-height. nSequence\u003e=0x80000000 (most significant\n\u003ebit\n\u003e\u003e set) is not interpreted as a relative lock-time.\n\u003e\u003e\n\u003e\u003e https://github.com/maaku/bitcoin/tree/sequencenumbers3\n\u003e\u003e\n\u003e\u003e This repository not only inverts the sequence number, but also\n\u003einterprets\n\u003e\u003e it as a fixed-point number. This allows up to 5 year relative lock\n\u003etimes\n\u003e\u003e using blocks as units, and saves 12 low-order bits for future use.\n\u003eOr, up\n\u003e\u003e to about 2 year relative lock times using seconds as units, and saves\n\u003e4\n\u003e\u003e bits for future use without second-level granularity. More bits could\n\u003ebe\n\u003e\u003e recovered from time-based locktimes by choosing a higher granularity\n\u003e(a\n\u003e\u003e soft-fork change if done correctly).\n\u003e\u003e\n\u003e\u003e On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach\n\u003e\u003cmark at friedenbach.org\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e To follow up on this, let's say that you want to be able to have up\n\u003eto 1\n\u003e\u003e\u003e year relative lock-times. This choice is somewhat arbitrary and what\n\u003eI\n\u003e\u003e\u003e would like some input on, but I'll come back to this point.\n\u003e\u003e\u003e\n\u003e\u003e\u003e * 1 bit is necessary to enable/disable relative lock-time.\n\u003e\u003e\u003e\n\u003e\u003e\u003e * 1 bit is necessary to indicate whether seconds vs blocks as the\n\u003eunit\n\u003e\u003e\u003e of measurement.\n\u003e\u003e\u003e\n\u003e\u003e\u003e * 1 year of time with 1-second granularity requires 25 bits.\n\u003eHowever\n\u003e\u003e\u003e since blocks occur at approximately 10 minute intervals on average,\n\u003ehaving\n\u003e\u003e\u003e a relative lock-time significantly less than this interval doesn't\n\u003emake\n\u003e\u003e\u003e much sense. A granularity of 256 seconds would be greater than the\n\u003eNyquist\n\u003e\u003e\u003e frequency and requires only 17 bits.\n\u003e\u003e\u003e\n\u003e\u003e\u003e * 1 year of blocks with 1-block granularity requires 16 bits.\n\u003e\u003e\u003e\n\u003e\u003e\u003e So time-based relative lock time requires about 19 bits, and\n\u003eblock-based\n\u003e\u003e\u003e relative lock-time requires about 18 bits. That leaves 13 or 14 bits\n\u003efor\n\u003e\u003e\u003e other uses.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Assuming a maximum of 1-year relative lock-times. But what is an\n\u003e\u003e\u003e appropriate maximum to choose? The use cases I have considered have\n\u003eonly\n\u003e\u003e\u003e had lock times on the order of a few days to a month or so. However\n\u003eI would\n\u003e\u003e\u003e feel uncomfortable going less than a year for a hard maximum, and am\n\u003ehaving\n\u003e\u003e\u003e trouble thinking of any use case that would require more than a year\n\u003eof\n\u003e\u003e\u003e lock-time. Can anyone else think of a use case that requires \u003e1yr\n\u003erelative\n\u003e\u003e\u003e lock-time?\n\u003e\u003e\u003e\n\u003e\u003e\u003e TL;DR\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach\n\u003e\u003cmark at friedenbach.org\u003e\n\u003e\u003e\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e A power of 2 would be far more efficient here. The key question is\n\u003ehow\n\u003e\u003e\u003e\u003e long of a relative block time do you need? Figure out what the\n\u003emaximum\n\u003e\u003e\u003e\u003e should be ( I don't know what that would be, any ideas?) and then\n\u003esee how\n\u003e\u003e\u003e\u003e many bits you have left over.\n\u003e\u003e\u003e\u003e On Aug 23, 2015 7:23 PM, \"Jorge Timón\" \u003c\n\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\n\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 \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\u003e\u003e \u003e Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the\n\u003e\u003e\u003e\u003e\u003e \u003e discussion has any thought been given to represent one block\n\u003ewith more\n\u003e\u003e\u003e\u003e\u003e \u003e than one increment? This would leave additional space for\n\u003efuture\n\u003e\u003e\u003e\u003e\u003e \u003e signaling, or allow, for example, higher resolution numbers for\n\u003ea\n\u003e\u003e\u003e\u003e\u003e \u003e sharechain commitement.\n\u003e\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e\u003e No, I don't think anybody thought about this. I just explained\n\u003ethis to\n\u003e\u003e\u003e\u003e\u003e Pieter using \"for example, 10 instead of 1\".\n\u003e\u003e\u003e\u003e\u003e He suggested 600 increments so that it is more similar to\n\u003etimestamps.\n\u003e\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\u003e\n\u003e\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\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150916/6256d65f/attachment.html\u003e",
"sig": "85293d1e092e8b9f20cb39b02ab94ab455a02010313fd824be514c5ebc20e63aac90df322709f778d05fa633cb0265e09c7475fc3fc0613fb28be48842b4f7a1"
}