📅 Original date posted:2015-08-25
📝 Original message: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/20150825/9e9f488e/attachment.html>;
Mark Friedenbach [ARCHIVE] /
npub1r3…48d0u
2023-06-07 15:46:52
in reply to nevent1q…f2jq
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uPublished at
2023-06-07 15:46:52Event JSON
{
"id": "cd77cfed82543c2643012432dd7b4c6459e8d6bf2f1944d973ff63c172e47ba2",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686152812,
"kind": 1,
"tags": [
[
"e",
"6086ec24c7436956a4324b488abdb6aa06edbf1e682d11a0a5b70b6f8e62e6f3",
"",
"root"
],
[
"e",
"2b598cde1c44586f4c1742e22dfb7b5f38095cfe48e6d5ace358bbe730e78c09",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2015-08-25\n📝 Original message:To follow up on this, let's say that you want to be able to have up to 1\nyear relative lock-times. This choice is somewhat arbitrary and what I\nwould like some input on, but I'll come back to this point.\n\n * 1 bit is necessary to enable/disable relative lock-time.\n\n * 1 bit is necessary to indicate whether seconds vs blocks as the unit of\nmeasurement.\n\n * 1 year of time with 1-second granularity requires 25 bits. However since\nblocks occur at approximately 10 minute intervals on average, having a\nrelative lock-time significantly less than this interval doesn't make much\nsense. A granularity of 256 seconds would be greater than the Nyquist\nfrequency and requires only 17 bits.\n\n * 1 year of blocks with 1-block granularity requires 16 bits.\n\nSo time-based relative lock time requires about 19 bits, and block-based\nrelative lock-time requires about 18 bits. That leaves 13 or 14 bits for\nother uses.\n\nAssuming a maximum of 1-year relative lock-times. But what is an\nappropriate maximum to choose? The use cases I have considered have only\nhad lock times on the order of a few days to a month or so. However I would\nfeel uncomfortable going less than a year for a hard maximum, and am having\ntrouble thinking of any use case that would require more than a year of\nlock-time. Can anyone else think of a use case that requires \u003e1yr relative\nlock-time?\n\nTL;DR\n\nOn Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\nwrote:\n\n\u003e A power of 2 would be far more efficient here. The key question is how\n\u003e long of a relative block time do you need? Figure out what the maximum\n\u003e should be ( I don't know what that would be, any ideas?) and then see how\n\u003e many bits you have left over.\n\u003e On Aug 23, 2015 7:23 PM, \"Jorge Timón\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the\n\u003e\u003e \u003e discussion has any thought been given to represent one block with more\n\u003e\u003e \u003e than one increment? This would leave additional space for future\n\u003e\u003e \u003e signaling, or allow, for example, higher resolution numbers for a\n\u003e\u003e \u003e sharechain commitement.\n\u003e\u003e\n\u003e\u003e No, I don't think anybody thought about this. I just explained this to\n\u003e\u003e Pieter using \"for example, 10 instead of 1\".\n\u003e\u003e He suggested 600 increments so that it is more similar to timestamps.\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150825/9e9f488e/attachment.html\u003e",
"sig": "9f1aab80a6beae7b88cc4b7e59a867fa5fc910d045bea11d5c34ed2aabb4ab19cbfc385ec402c956bc552100ed7af033a8831a54dda78d5901edd23baab375a5"
}