Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1614AF74 for ; 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 ; Thu, 27 Aug 2015 23:33:15 +0000 (UTC) Received: by iodt126 with SMTP id t126so75645485iod.2 for ; 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: References: <55DA6470.9040301@thinlink.com> From: Mark Friedenbach Date: Thu, 27 Aug 2015 16:32:55 -0700 Message-ID: Cc: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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 >>> 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
So I've created 2 new repositories with chan= ged rules regarding sequencenumbers:

https://github.com/maaku/bitcoin/tree/s= equencenumbers2

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.

https://github.com/maaku/bitcoin/tree/sequencenumbers3

=
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).

On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach <mark@friedenbach.org> wrote:
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.

=C2=A0* 1 bit is necessary to enable/d= isable relative lock-time.

=C2=A0* 1 bit is ne= cessary to indicate whether seconds vs blocks as the unit of measurement.
=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.

= =C2=A0* 1 year of blocks with 1-block granularity requires 16 bits.

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.

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?

TL;DR <= br>

On Sun, Aug 23, 2015 at 7:37 PM, Mark Fried= enbach <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 i= deas?) and then see how many bits you have left over.

On Aug 23, 2015 7:23 PM, "Jorge Tim=C3=B3n&= quot; <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Mon, Aug 24, 2015 at 3:01 A= M, 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?=C2=A0 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<= br> 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/mail= man/listinfo/bitcoin-dev


--001a113f9694224806051e536422--