From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C7B47BF4 for ; Tue, 25 Aug 2015 22:08:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f170.google.com (mail-ig0-f170.google.com [209.85.213.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C046812E for ; Tue, 25 Aug 2015 22:08:52 +0000 (UTC) Received: by igcse8 with SMTP id se8so25298578igc.1 for ; Tue, 25 Aug 2015 15:08:52 -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=RnxmZfp8UD1DFEFCcjH3ywZJxl9r9sj83Mb0oYNI4cE=; b=Cb1GBpgaijCcjnj519DRebNR/mdY6+Mj3/JWW425dSl8VaXH5K1K0EM8PD6YUfIl9o f61vdbf2qkbXuWe0wK5BfakhGirJvxXHzROfiqfPpisqRuHm9kgdJFtxqXdGEtk60xDC zzTiJ16/U3i2Iv08dgc/llLlCczuPocDVfMmDuwydg4FAFNUMb9c5JP5csVU+CCUwVlS 7X//lekUumiOKoNWf1lYGxUuRbmxPaQh4H4q8mf40QIHSI8znQFrNFhIeJ59m6cJ1Mwi K2/RCHnuGLoSEfThE9PWUO/xbnP3IV7vatOUaZs5PZtBhW4KR8NxJCgBapCG8zls+iG9 8eHg== X-Gm-Message-State: ALoCoQnbshFPkcFsfMICJEDPGjRIx2YaGPqVl16Z8NVmT90Qb4c2EezAhc/8AASXVYGAWnWfUi4z X-Received: by 10.50.102.4 with SMTP id fk4mr6872498igb.46.1440540532167; Tue, 25 Aug 2015 15:08:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.14 with HTTP; Tue, 25 Aug 2015 15:08:32 -0700 (PDT) X-Originating-IP: [24.4.96.213] In-Reply-To: References: <55DA6470.9040301@thinlink.com> From: Mark Friedenbach Date: Tue, 25 Aug 2015 15:08:32 -0700 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=047d7b11198db4c03d051e29facb 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: 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: Tue, 25 Aug 2015 22:08:53 -0000 --047d7b11198db4c03d051e29facb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=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 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 >> > --047d7b11198db4c03d051e29facb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 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 blo= ck time do you need? Figure out what the maximum should be ( I don't kn= ow 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&= 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

--047d7b11198db4c03d051e29facb--