📅 Original date posted:2015-08-27
📝 Original message: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
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/47ea68ac/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 17:35:00
in reply to nevent1q…0tx4
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 17:35:00Event JSON
{
"id": "42f9c383aefd05d0bd0ccec8bb0f969a2162150c45fc427872bd9fb309b7f95c",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686159300,
"kind": 1,
"tags": [
[
"e",
"41b744fb00dece0ad755afb2bd169d7e5d2189a91240037a08b3b215596a998e",
"",
"root"
],
[
"e",
"709fe45a8e0a5476c57ccb47421292c3fb7cf8cc263be4a281c376bd4e922ef9",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 Original date posted:2015-08-27\n📝 Original message:So I've created 2 new repositories with changed rules regarding\nsequencenumbers:\n\nhttps://github.com/maaku/bitcoin/tree/sequencenumbers2\n\nThis repository inverts (un-inverts?) the sequence number. nSequence=1\nmeans 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1\nsecond relative lock-height. nSequence\u003e=0x80000000 (most significant bit\nset) is not interpreted as a relative lock-time.\n\nhttps://github.com/maaku/bitcoin/tree/sequencenumbers3\n\nThis repository not only inverts the sequence number, but also interprets\nit as a fixed-point number. This allows up to 5 year relative lock times\nusing blocks as units, and saves 12 low-order bits for future use. Or, up\nto about 2 year relative lock times using seconds as units, and saves 4\nbits for future use without second-level granularity. More bits could be\nrecovered from time-based locktimes by choosing a higher granularity (a\nsoft-fork change if done correctly).\n\nOn Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\nwrote:\n\n\u003e To follow up on this, let's say that you want to be able to have up to 1\n\u003e year relative lock-times. This choice is somewhat arbitrary and what I\n\u003e would like some input on, but I'll come back to this point.\n\u003e\n\u003e * 1 bit is necessary to enable/disable relative lock-time.\n\u003e\n\u003e * 1 bit is necessary to indicate whether seconds vs blocks as the unit of\n\u003e measurement.\n\u003e\n\u003e * 1 year of time with 1-second granularity requires 25 bits. However\n\u003e since blocks occur at approximately 10 minute intervals on average, having\n\u003e a relative lock-time significantly less than this interval doesn't make\n\u003e much sense. A granularity of 256 seconds would be greater than the Nyquist\n\u003e frequency and requires only 17 bits.\n\u003e\n\u003e * 1 year of blocks with 1-block granularity requires 16 bits.\n\u003e\n\u003e So time-based relative lock time requires about 19 bits, and block-based\n\u003e relative lock-time requires about 18 bits. That leaves 13 or 14 bits for\n\u003e other uses.\n\u003e\n\u003e Assuming a maximum of 1-year relative lock-times. But what is an\n\u003e appropriate maximum to choose? The use cases I have considered have only\n\u003e had lock times on the order of a few days to a month or so. However I would\n\u003e feel uncomfortable going less than a year for a hard maximum, and am having\n\u003e trouble thinking of any use case that would require more than a year of\n\u003e lock-time. Can anyone else think of a use case that requires \u003e1yr relative\n\u003e lock-time?\n\u003e\n\u003e TL;DR\n\u003e\n\u003e On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e A power of 2 would be far more efficient here. The key question is how\n\u003e\u003e long of a relative block time do you need? Figure out what the maximum\n\u003e\u003e should be ( I don't know what that would be, any ideas?) and then see how\n\u003e\u003e many bits you have left over.\n\u003e\u003e On Aug 23, 2015 7:23 PM, \"Jorge Timón\" \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev\n\u003e\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the\n\u003e\u003e\u003e \u003e discussion has any thought been given to represent one block with more\n\u003e\u003e\u003e \u003e than one increment? This would leave additional space for future\n\u003e\u003e\u003e \u003e signaling, or allow, for example, higher resolution numbers for a\n\u003e\u003e\u003e \u003e sharechain commitement.\n\u003e\u003e\u003e\n\u003e\u003e\u003e No, I don't think anybody thought about this. I just explained this to\n\u003e\u003e\u003e Pieter using \"for example, 10 instead of 1\".\n\u003e\u003e\u003e He suggested 600 increments so that it is more similar to timestamps.\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/47ea68ac/attachment.html\u003e",
"sig": "7f7f855dd67c3b31942f59accdc1288658910b6590207e9a86ac1c2390b3bb14fbde87c476a2c5988b4d02dad9591cf06445e5cdb0ebd268abc113b08ba7db5e"
}