Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BD9F21664 for ; 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 ; Wed, 16 Sep 2015 23:23:15 +0000 (UTC) Received: by ioii196 with SMTP id i196so4290838ioi.3 for ; 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: References: <55DA6470.9040301@thinlink.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----BAFW7MI8ZBPZVB5B8Q8H24T2GZQP84" Content-Transfer-Encoding: 8bit From: Eric Lombrozo Date: Wed, 16 Sep 2015 19:23:18 -0400 To: Btc Drak , Btc Drak via bitcoin-dev , Mark Friedenbach 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 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 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 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 > >> 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 > >>> 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 >>>>> 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 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--