Return-Path: <mark@friedenbach.org> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 62AA8E55 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 17 Sep 2015 04:24:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 51E5E12E for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 17 Sep 2015 04:24:01 +0000 (UTC) Received: by iofb144 with SMTP id b144so9748716iof.1 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 16 Sep 2015 21:24:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=02fxMbKqtlfzFfjIGT4ACKpRNkiZBcnoKMx27/QsZyA=; b=Zj17AbHrw02ccu9jq7T85tzGIIXHuzH0c3BoaBPNkaZ9QwD6uTeUcyOxPUV1AsdE5e lZDK734Jxbe3Hyn/ogYsdZibYlt/SE5NSLlV+kXSwm8jycYb/0bBiY/ZW4bPykcD+xz3 JFqU595/OV9+5PzmdqON/G4eFGCVIUfdPspuUd3YPfdylUDRPIsP3j6pufknPo6RQHTd gOiurS2KPibbzYbGJ/uhjm9hEZZUwRZLp0KH9Gvm+Wy1eJT3jlGRrG4r8IaVicRyQCGQ 11cs4wdxove+UFdfmbmWhmrSnS3QtWtYKIz8Me1RMOVZH28bwN9zVLSzPsVyhkdW9tf3 O+qA== X-Gm-Message-State: ALoCoQmOdftNL9LR7NIs/JGeShE+n7G61ZzxT8dSBk3P7wus6CUbZ8zWXTsl2xaJPTBUfvVOmJjy X-Received: by 10.107.11.154 with SMTP id 26mr2690367iol.105.1442463840762; Wed, 16 Sep 2015 21:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.135.104 with HTTP; Wed, 16 Sep 2015 21:23:41 -0700 (PDT) X-Originating-IP: [66.130.36.70] In-Reply-To: <4E3B7469-1018-4649-8DF1-6597F82774F1@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> <4E3B7469-1018-4649-8DF1-6597F82774F1@gmail.com> From: Mark Friedenbach <mark@friedenbach.org> Date: Thu, 17 Sep 2015 00:23:41 -0400 Message-ID: <CAOG=w-u2b9BTNyAxdzEnOxazr1Gc_Yrf5CxCfrjeJi39NV=cgQ@mail.gmail.com> To: Eric Lombrozo <elombrozo@gmail.com> Content-Type: multipart/alternative; boundary=001a113f7e7cd4a547051fe9c866 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Btc Drak via 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: Thu, 17 Sep 2015 04:24:02 -0000 --001a113f7e7cd4a547051fe9c866 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eric, that would be, I think, my sequencenumbers2 branch in which nSequence is an explicit relative lock-time field (unless the most significant bit is set). That has absolutely clear semantics. You should comment on #6312 where this is being discussed. On Wed, Sep 16, 2015 at 7:23 PM, Eric Lombrozo <elombrozo@gmail.com> wrote: > 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=3D= 1 >>> means 1 block relative lock-height. nSequence=3DLOCKTIME_THRESHOLD mean= s 1 >>> second relative lock-height. nSequence>=3D0x80000000 (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 relativ= e >>> lock times using blocks as units, and saves 12 low-order bits for futur= e >>> 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 uni= t >>>> of measurement. >>>> >>>> * 1 year of time with 1-second granularity requires 25 bits. However >>>> since blocks occur at approximately 10 minute intervals on average, ha= ving >>>> a relative lock-time significantly less than this interval doesn't mak= e >>>> much sense. A granularity of 256 seconds would be greater than the Nyq= uist >>>> 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 on= ly >>>> 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 h= aving >>>> trouble thinking of any use case that would require more than a year o= f >>>> lock-time. Can anyone else think of a use case that requires >1yr rela= tive >>>> lock-time? >>>> >>>> TL;DR >>>> >>>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <mark@friedenbach.or= g >>>> > wrote: >>>> >>>>> A power of 2 would be far more efficient here. The key question is ho= w >>>>> long of a relative block time do you need? Figure out what the maximu= m >>>>> 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=C3=B3n" < >>>>> 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. > --001a113f7e7cd4a547051fe9c866 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Eric, that would be, I think, my sequencenumbers2 branch i= n which nSequence is an explicit relative lock-time field (unless the most = significant bit is set). That has absolutely clear semantics. You should co= mment on #6312 where this is being discussed.<br></div><div class=3D"gmail_= extra"><br><div class=3D"gmail_quote">On Wed, Sep 16, 2015 at 7:23 PM, Eric= Lombrozo <span dir=3D"ltr"><<a href=3D"mailto:elombrozo@gmail.com" targ= et=3D"_blank">elombrozo@gmail.com</a>></span> wrote:<br><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex"><div>I'd rather replace the whole nSequence thing with a= n explicit relative locktime with clear semantics...but I'm not going t= o fight this one too much.<div><div class=3D"h5"><br><br><div class=3D"gmai= l_quote">On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev <= ;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"= >bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<blockquote class=3D"g= mail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex"> <div dir=3D"ltr">Where do we stand now on which=C2=A0sequencenumbers variat= ion to use? We really should make a decision now.</div><div class=3D"gmail_= extra"><br><div class=3D"gmail_quote">On Fri, Aug 28, 2015 at 12:32 AM, Mar= k Friedenbach via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitco= in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux= foundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div= dir=3D"ltr"><div><div>So I've created 2 new repositories with changed = rules regarding sequencenumbers:<br><br><a href=3D"https://github.com/maaku= /bitcoin/tree/sequencenumbers2" target=3D"_blank">https://github.com/maaku/= bitcoin/tree/sequencenumbers2</a><br><br></div>This repository inverts (un-= inverts?) the sequence number. nSequence=3D1 means 1 block relative lock-he= ight. nSequence=3DLOCKTIME_THRESHOLD means 1 second relative lock-height. n= Sequence>=3D0x80000000 (most significant bit set) is not interpreted as a relative lock-time.<br><br><a = href=3D"https://github.com/maaku/bitcoin/tree/sequencenumbers3" target=3D"_= blank">https://github.com/maaku/bitcoin/tree/sequencenumbers3</a><br><br></= div>This repository not only inverts the sequence number, but also interpre= ts 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 bit= s for future use without second-level granularity. More bits could be recov= ered from time-based locktimes by choosing a higher granularity (a soft-for= k change if done correctly).<br></div><div><div><div class=3D"gmail_extra">= <br><div class=3D"gmail_quote">On Tue, Aug 25, 2015 at 3:08 PM, Mark Friede= nbach <span dir=3D"ltr"><<a href=3D"mailto:mark@friedenbach.org" target= =3D"_blank">mark@friedenbach.org</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"><div dir=3D"ltr"><div><div>To follow up on this, let's sa= y that you want to be able to have up to 1 year relative lock-times. This c= hoice is somewhat arbitrary and what I would like some input on, but I'= ll come back to this point.<br><br></div><div>=C2=A0* 1 bit is necessary to= enable/disable relative lock-time.<br></div><div><br></div><div>=C2=A0* 1 = bit is necessary to indicate whether seconds vs blocks as the unit of measu= rement.<br><br></div><div>=C2=A0* 1 year of time with 1-second granularity = requires 25 bits. However since blocks occur at approximately 10 minute int= ervals on average, having a relative lock-time significantly less than this= interval doesn't make much sense. A granularity of 256 seconds would b= e greater than the Nyquist frequency and requires only 17 bits.<br><br></di= v><div>=C2=A0* 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 leave= s 13 or 14 bits for other uses.<br><br></div><div>Assuming a maximum of 1-y= ear 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 th= at 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><div><div class=3D"gmail_extra"><br><div class=3D"gmai= l_quote">On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <span dir=3D"ltr= "><<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friede= nbach.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir= =3D"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><div> <div class=3D"gmail_quote">On Aug 23, 2015 7:23 PM, "Jorge Tim=C3=B3n&= quot; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= =3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D= "attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex">On Mon, Aug 24, 2015 at 3:01 A= M, Gregory Maxwell via bitcoin-dev<br> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla= nk">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?=C2=A0 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=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/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=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> <br></blockquote></div><br></div> <p style=3D"margin-top:2.5em;margin-bottom:1em;border-bottom:1px solid #000= "></p><pre><hr><br>bitcoin-dev mailing list<br><a href=3D"mailto:bitcoin-de= v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound= ation.org</a><br><a href=3D"https://lists.linuxfoundation.org/mailman/listi= nfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailma= n/listinfo/bitcoin-dev</a><br></pre></blockquote></div><br></div></div><spa= n class=3D"HOEnZb"><font color=3D"#888888"> -- <br> Sent from my Android device with K-9 Mail. Please excuse my brevity.</font>= </span></div></blockquote></div><br></div> --001a113f7e7cd4a547051fe9c866--