<div dir="ltr"><div><div>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.<br><br></div><div> * 1 bit is necessary to enable/disable relative lock-time.<br></div><div><br></div><div> * 1 bit is necessary to indicate whether seconds vs blocks as the unit of measurement.<br><br></div><div> * 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.<br><br></div><div> * 1 year of blocks with 1-block granularity requires 16 bits.<br></div><div><br></div>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.<br><br></div><div>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?<br></div><div><br></div>TL;DR <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <span dir="ltr"><<a href="mailto:mark@friedenbach.org" target="_blank">mark@friedenbach.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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.</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Aug 23, 2015 7:23 PM, "Jorge Timón" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev<br>
<<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the<br>
> discussion has any thought been given to represent one block with more<br>
> than one increment? This would leave additional space for future<br>
> signaling, or allow, for example, higher resolution numbers for a<br>
> sharechain commitement.<br>
<br>
No, I don't think anybody thought about this. I just explained this to<br>
Pieter using "for example, 10 instead of 1".<br>
He suggested 600 increments so that it is more similar to timestamps.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div></div></blockquote></div><br></div>