Mark Friedenbach [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-25 📝 Original message:To follow up on this, ...
📅 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>;
📝 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>;