From mboxrd@z Thu Jan 1 00:00:00 1970 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 1614AF74 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 27 Aug 2015 23:33:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E31213C for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 27 Aug 2015 23:33:15 +0000 (UTC) Received: by iodt126 with SMTP id t126so75645485iod.2 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 27 Aug 2015 16:33:14 -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:cc:content-type; bh=b7FJE4hxIUVTXkLl/Z9ANUs6/4xq4uKWOmRNe6jMsnc=; b=ZnQC0ixhvwKp5jCpHL6bV4z7h/irQjsbedl4slZEKXZ9+ZZGjbD4El7WTCS+6AwavW zruqQ9B7jKrqHuow+bGIeF+G93x/NDCKkNq3FcxSnfkoAA3Qlxg9gdGLuFGV9pg9KgyQ vMEmKuzzuQ1f9Q3ZTpI6DmxkIeV0cDMBJTz3CbKk/GnIipzQFk2bTVOQ0C3PmkO9SqzL 1FFNWrzuanxOhuS7mac/lb/cbe5L5R/DheGzxujUWmo2PmnI46Nj1ce83oskhCGPLvLk zzeBB7KxCKi2PXWnlrvQldBRVe0RBatrtTvnsTw5oiTrFsCTM8VMB6/SylbalDK27eZP yKuQ== X-Gm-Message-State: ALoCoQn9bB90Fe2JwWF1A5ydyh9NMeAm+R2tvcxtZJgy85E50UFp1f6zmy9BbcABBEtZIVcYKJLJ X-Received: by 10.107.11.67 with SMTP id v64mr13470761ioi.105.1440718394634; Thu, 27 Aug 2015 16:33:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.135.104 with HTTP; Thu, 27 Aug 2015 16:32:55 -0700 (PDT) X-Originating-IP: [24.4.96.213] In-Reply-To: <CAOG=w-to4Vrx4ykKJTy5EAyN4GZd6Q=G5FzqZH-5J3Thz_VNpQ@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> From: Mark Friedenbach <mark@friedenbach.org> Date: Thu, 27 Aug 2015 16:32:55 -0700 Message-ID: <CAOG=w-tuFtX2t+0FVfkoObw_a9-7j4LwX87YJU1n7adYu=DMdQ@mail.gmail.com> Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> Content-Type: multipart/alternative; boundary=001a113f9694224806051e536422 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.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, 27 Aug 2015 23:33:16 -0000 --001a113f9694224806051e536422 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=3D1 means 1 block relative lock-height. nSequence=3DLOCKTIME_THRESHOLD means 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 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 o= f > measurement. > > * 1 year of time with 1-second granularity requires 25 bits. However > since blocks occur at approximately 10 minute intervals on average, havin= g > a relative lock-time significantly less than this interval doesn't make > much sense. A granularity of 256 seconds would be greater than the Nyquis= t > 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 wou= ld > feel uncomfortable going less than a year for a hard maximum, and am havi= ng > 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 relativ= e > 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 ho= w >> 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 mor= e >>> > 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 >>> >> > --001a113f9694224806051e536422 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>So I've created 2 new repositories with chan= ged rules regarding sequencenumbers:<br><br><a href=3D"https://github.com/m= aaku/bitcoin/tree/sequencenumbers2">https://github.com/maaku/bitcoin/tree/s= equencenumbers2</a><br><br></div>This repository inverts (un-inverts?) the = sequence number. nSequence=3D1 means 1 block relative lock-height. nSequenc= e=3DLOCKTIME_THRESHOLD means 1 second relative lock-height. nSequence>= =3D0x80000000 (most significant bit set) is not interpreted as a relative l= ock-time.<br><br><a href=3D"https://github.com/maaku/bitcoin/tree/sequencen= umbers3">https://github.com/maaku/bitcoin/tree/sequencenumbers3</a><br><br>= </div>This repository not only inverts the sequence number, but also interp= rets it as a fixed-point number. This allows up to 5 year relative lock tim= es using blocks as units, and saves 12 low-order bits for future use. Or, u= p to about 2 year relative lock times using seconds as units, and saves 4 b= its for future use without second-level granularity. More bits could be rec= overed from time-based locktimes by choosing a higher granularity (a soft-f= ork change if done correctly).<br></div><div class=3D"gmail_extra"><br><div= class=3D"gmail_quote">On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach <s= pan dir=3D"ltr"><<a href=3D"mailto:mark@friedenbach.org" target=3D"_blan= k">mark@friedenbach.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"><div dir=3D"ltr"><div><div>To follow up on this, let's say that yo= u 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 b= ack to this point.<br><br></div><div>=C2=A0* 1 bit is necessary to enable/d= isable relative lock-time.<br></div><div><br></div><div>=C2=A0* 1 bit is ne= cessary to indicate whether seconds vs blocks as the unit of measurement.<b= r><br></div><div>=C2=A0* 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>= =C2=A0* 1 year of blocks with 1-block granularity requires 16 bits.<br></di= v><div><br></div>So time-based relative lock time requires about 19 bits, a= nd 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 rel= ative lock-times. But what is an appropriate maximum to choose? The use cas= es 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 f= or a hard maximum, and am having trouble thinking of any use case that woul= d require more than a year of lock-time. Can anyone else think of a use cas= e that requires >1yr relative lock-time?<br></div><div><br></div>TL;DR <= br></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"= ><br><div class=3D"gmail_quote">On Sun, Aug 23, 2015 at 7:37 PM, Mark Fried= enbach <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"><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 i= deas?) 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> --001a113f9694224806051e536422--