+Return-Path: <elombrozo@gmail.com>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id BD9F21664

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 16 Sep 2015 23:23:16 +0000 (UTC)

+X-Greylist: whitelisted by SQLgrey-1.7.6

+Received: from mail-io0-f175.google.com (mail-io0-f175.google.com

+ [209.85.223.175])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C706145

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 16 Sep 2015 23:23:15 +0000 (UTC)

+Received: by ioii196 with SMTP id i196so4290838ioi.3

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Wed, 16 Sep 2015 16:23:15 -0700 (PDT)

+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;

+ h=user-agent:in-reply-to:references:mime-version:content-type

+ :content-transfer-encoding:subject:from:date:to:cc:message-id;

+ bh=veVvK0VYe7Sg8IbQcCDWLly6ZKexuwOLt4nkksMDYHg=;

+ b=lgOYgJhGb5JIwJeU4yBp/naXdPZhmWSBI96VB8UNNlwAWRLuAl4TAUJpC2xBmbQtiJ

+ MfU75dxOOpCfYzhxyfntOL7150GUX90EmiitWv6ebZHpxOYJuEhEDoga0Oph6HoAqYjr

+ zWQZrrESWxsHAO+cTbPwPbchPDTovkB/nVq+OsyfCL6qL0Mua2em57mWPi/IbGaD25c2

+ gIDPm3RBBXu6lgQSIcbNo8miLlWA8igXTz4iddl02DGOAxcsfqbY7tfCoZ3g9RbVyWKY

+ ZVdmNSH1hulPRgtfxkiae5nVA7OpXijzb1M87tagOe1VDT+D2a2uN8gZBIsuAEOEIY8z

+ TFmA==

+X-Received: by 10.107.135.196 with SMTP id r65mr1149349ioi.131.1442445795116;

+ Wed, 16 Sep 2015 16:23:15 -0700 (PDT)

+Received: from android-497033634a7205c7 ([24.114.98.80])

+ by smtp.gmail.com with ESMTPSA id o2sm2977054igr.9.2015.09.16.16.23.14

+ (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);

+ Wed, 16 Sep 2015 16:23:14 -0700 (PDT)

+User-Agent: K-9 Mail for Android

+In-Reply-To: <CADJgMzsPrg7VhTQC8aCvcQ3yAN8rtt+Qv_yfrCKMqOALpGPVyg@mail.gmail.com>

+References: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com>

+ <CADJgMzv8G3EqLBwEYRHJZ+fO_Jwzy0koi2pJ_iNRkXmoVarGcg@mail.gmail.com>

+ <CABm2gDod9z6ksgaCv86qFCyKLTQSL3+oNns+__5H77hVhs05DQ@mail.gmail.com>

+ <CAOG=w-sbOcaogkic2i4A5eZnBQ79LUibsGy0dyKyvQg53ktY1Q@mail.gmail.com>

+ <55DA6470.9040301@thinlink.com>

+ <CAAS2fgQKQpHu-nC1uSrigDx2JLUt64p-LqidVmiuULDE0MJCFQ@mail.gmail.com>

+ <CABm2gDqW7OGuyZ1BTTeeivDf9wFVsAK9AaGYm8XWwLb2O2Lb+g@mail.gmail.com>

+ <CAOG=w-ubk3nPfxy25Hd6kPeehf7vnYD5chksLWU5wU2t=jL5TA@mail.gmail.com>

+ <CAOG=w-to4Vrx4ykKJTy5EAyN4GZd6Q=G5FzqZH-5J3Thz_VNpQ@mail.gmail.com>

+ <CAOG=w-tuFtX2t+0FVfkoObw_a9-7j4LwX87YJU1n7adYu=DMdQ@mail.gmail.com>

+ <CADJgMzsPrg7VhTQC8aCvcQ3yAN8rtt+Qv_yfrCKMqOALpGPVyg@mail.gmail.com>

+MIME-Version: 1.0

+Content-Type: multipart/alternative;

+ boundary="----BAFW7MI8ZBPZVB5B8Q8H24T2GZQP84"

+Content-Transfer-Encoding: 8bit

+From: Eric Lombrozo <elombrozo@gmail.com>

+Date: Wed, 16 Sep 2015 19:23:18 -0400

+To: Btc Drak <btcdrak@gmail.com>,

+ Btc Drak via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,

+ Mark Friedenbach <mark@friedenbach.org>

+Message-ID: <4E3B7469-1018-4649-8DF1-6597F82774F1@gmail.com>

+X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,

+ DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW

+ autolearn=ham version=3.3.1

+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on

+ smtp1.linux-foundation.org

+Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>

+Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for

+ relative locktime

+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org

+X-Mailman-Version: 2.1.12

+Precedence: list

+List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>

+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>

+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>

+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>

+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>

+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>

+X-List-Received-Date: Wed, 16 Sep 2015 23:23:16 -0000

+

+------BAFW7MI8ZBPZVB5B8Q8H24T2GZQP84

+Content-Transfer-Encoding: 8bit

+Content-Type: text/plain;

+ charset=UTF-8

+

+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@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@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@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@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@lists.linuxfoundation.org> wrote:

+>>>>

+>>>>> On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev

+>>>>> <bitcoin-dev@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@lists.linuxfoundation.org

+>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

+>>>>>

+>>>>

+>>>

+>>

+>> _______________________________________________

+>> bitcoin-dev mailing list

+>> bitcoin-dev@lists.linuxfoundation.org

+>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

+>>

+>>

+>

+>

+>------------------------------------------------------------------------

+>

+>_______________________________________________

+>bitcoin-dev mailing list

+>bitcoin-dev@lists.linuxfoundation.org

+>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

+

+--

+Sent from my Android device with K-9 Mail. Please excuse my brevity.

+------BAFW7MI8ZBPZVB5B8Q8H24T2GZQP84

+Content-Type: text/html;

+ charset=utf-8

+Content-Transfer-Encoding: 8bit

+

+<html><head></head><body>I&#39;d rather replace the whole nSequence thing with an explicit relative locktime with clear semantics...but I&#39;m not going to fight this one too much.<br><br><div class="gmail_quote">On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

+<div dir="ltr">Where do we stand now on which sequencenumbers variation to use? We really should make a decision now.</div><div class="gmail_extra"><br /><div class="gmail_quote">On Fri, Aug 28, 2015 at 12:32 AM, Mark Friedenbach via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>So I&#39;ve created 2 new repositories with changed rules regarding sequencenumbers:<br /><br /><a href="https://github.com/maaku/bitcoin/tree/sequencenumbers2" target="_blank">https://github.com/maaku/bitcoin/tree/sequencenumbers2</a><br /><br /></div>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&gt;=0x80000000 (most

+significant bit set) is not interpreted as a relative lock-time.<br /><br /><a href="https://github.com/maaku/bitcoin/tree/sequencenumbers3" target="_blank">https://github.com/maaku/bitcoin/tree/sequencenumbers3</a><br /><br /></div>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).<br /></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br /><div class="gmail_quote">On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach <span dir="ltr">&lt;<a href="mailto:mark@friedenbach.org" target="_blank">mark@friedenbach.org</a>&gt;</span> wrote:<br /><blockq

+ uote

+class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>To follow up on this, let&#39;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&#39;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&#39;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 &gt;1yr relative lock-time?<br /></div><div><br /></div>TL;DR <br /></div><div><div><div class="gmail_extra"><br /><div class="gmail_quote">On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <span dir="ltr">&lt;<a href="mailto:mark@friedenbach.org" target="_blank">mark@friedenbach.org</a>&gt;</span> wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-lef

+ t: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&#39;t know what that would be, any ideas?) and then see how many bits you have left over.</p><div><div>

+<div class="gmail_quote">On Aug 23, 2015 7:23 PM, &quot;Jorge Timón&quot; &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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 />

+&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br />

+&gt; Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the<br />

+&gt; discussion has any thought been given to represent one block with more<br />

+&gt; than one increment?  This would leave additional space for future<br />

+&gt; signaling, or allow, for example, higher resolution numbers for a<br />

+&gt; sharechain commitement.<br />

+<br />

+No, I don&#39;t think anybody thought about this. I just explained this to<br />

+Pieter using &quot;for example, 10 instead of 1&quot;.<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>

+</div></div></blockquote></div><br /></div>

+</div></div><br />_______________________________________________<br />

+bitcoin-dev mailing list<br />

+<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">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 />

+<br /></blockquote></div><br /></div>

+<p style="margin-top: 2.5em; margin-bottom: 1em; border-bottom: 1px solid #000"></p><pre class="k9mail"><hr /><br />bitcoin-dev mailing list<br />bitcoin-dev@lists.linuxfoundation.org<br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /></pre></blockquote></div><br>

+-- <br>

+Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>

+------BAFW7MI8ZBPZVB5B8Q8H24T2GZQP84--

+

+