Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1146314DD for ; Wed, 16 Sep 2015 22:40:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A93FAFF for ; Wed, 16 Sep 2015 22:40:27 +0000 (UTC) Received: by wicgb1 with SMTP id gb1so94061511wic.1 for ; Wed, 16 Sep 2015 15:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KY/++zR5AVfJd+ZCZO76KtblKUO64DTg8pJCmdP+rwg=; b=vgCn+x8duXqnxssvxRDuCfu4mdpIZb+1/AXzO8a/uco7dmP8RFvSTIRgbIzw/ukjSx iMP+sjWgYMzXlDlU7pEx99w9yQLR2spT05zR9nb3g6CHPVgNJR7SsasIdPPxpYihPgI0 WSu1C26k2l5ozqsCkxRgvoAJIcqxMHZy72dbmMq2fvR/riuY+pvyQrFjIEIWGyS8Lu0a 4plW83x7EXjJCbtxy/9+zXAzLYN5GnocNd3/+NxyMDZWq0lpIC6Fm8toS4mn+b8lAZrN kK4s9Ci5zKZCuOCGNCFwSw55pO6kej0DFCR+GxB/UAeE1u5mt2/4cgIbsHHheNWXJRQl juLw== X-Received: by 10.194.121.131 with SMTP id lk3mr25835314wjb.77.1442443226450; Wed, 16 Sep 2015 15:40:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.21.200 with HTTP; Wed, 16 Sep 2015 15:40:06 -0700 (PDT) In-Reply-To: References: <55DA6470.9040301@thinlink.com> From: Btc Drak Date: Wed, 16 Sep 2015 23:40:06 +0100 Message-ID: To: Mark Friedenbach Content-Type: multipart/alternative; boundary=089e01227b8a1f0f58051fe4fce7 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, HTML_MESSAGE,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 Cc: Bitcoin Dev 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: Wed, 16 Sep 2015 22:40:29 -0000 --089e01227b8a1f0f58051fe4fce7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=3D1 > means 1 block relative lock-height. nSequence=3DLOCKTIME_THRESHOLD means = 1 > second relative lock-height. nSequence>=3D0x80000000 (most significant bi= t > 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 >> of measurement. >> >> * 1 year of time with 1-second granularity requires 25 bits. However >> since blocks occur at approximately 10 minute intervals on average, havi= ng >> a relative lock-time significantly less than this interval doesn't make >> much sense. A granularity of 256 seconds would be greater than the Nyqui= st >> 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 wo= uld >> feel uncomfortable going less than a year for a hard maximum, and am hav= ing >> 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 relati= ve >> 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 h= ow >>> 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 mo= re >>>> > 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 > > --089e01227b8a1f0f58051fe4fce7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Where do we stand now on which=C2=A0sequencenumbers variat= ion to use? We really should make a decision now.

On Fri, Aug 28, 2015 at 12:32 AM, Mar= k Friedenbach via bitcoin-dev <bitcoin-dev@lists.linux= foundation.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=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.

https://github.com/maaku/bitcoin/tre= e/sequencenumbers3

This repository not only inverts the se= quence 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-or= der bits for future use. Or, up to about 2 year relative lock times using s= econds as units, and saves 4 bits for future use without second-level granu= larity. 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 <ma= rk@friedenbach.org> wrote:
=
To follow up on this, let's say that you wan= t to be able to have up to 1 year relative lock-times. This choice is somew= hat arbitrary and what I would like some input on, but I'll come back t= o this point.

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

=C2=A0* 1 bit is necessa= ry to indicate whether seconds vs blocks as the unit of measurement.
=C2=A0* 1 year of time with 1-second granularity requires 25 bi= ts. However since blocks occur at approximately 10 minute intervals on aver= age, having a relative lock-time significantly less than this interval does= n'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, and bloc= k-based relative lock-time requires about 18 bits. That leaves 13 or 14 bit= s for other uses.

Assuming a maximum of 1-year relative l= ock-times. But what is an appropriate maximum to choose? The use cases I ha= ve considered have only had lock times on the order of a few days to a mont= h or so. However I would feel uncomfortable going less than a year for a ha= rd maximum, and am having trouble thinking of any use case that would requi= re more than a year of lock-time. Can anyone else think of a use case that = requires >1yr relative lock-time?

TL;DR

On Su= n, 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 r= elative block time do you need? Figure out what the maximum should be ( I d= on't know what that would be, any ideas?) and then see how many bits yo= u 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



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--089e01227b8a1f0f58051fe4fce7--