path: root/76/ddbacdc3eaea5c183262822f9a00de4df11bf4

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 62AA8E55
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 04:24:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com
	[209.85.223.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 51E5E12E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Sep 2015 04:24:01 +0000 (UTC)
Received: by iofb144 with SMTP id b144so9748716iof.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Sep 2015 21:24:00 -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=02fxMbKqtlfzFfjIGT4ACKpRNkiZBcnoKMx27/QsZyA=;
	b=Zj17AbHrw02ccu9jq7T85tzGIIXHuzH0c3BoaBPNkaZ9QwD6uTeUcyOxPUV1AsdE5e
	lZDK734Jxbe3Hyn/ogYsdZibYlt/SE5NSLlV+kXSwm8jycYb/0bBiY/ZW4bPykcD+xz3
	JFqU595/OV9+5PzmdqON/G4eFGCVIUfdPspuUd3YPfdylUDRPIsP3j6pufknPo6RQHTd
	gOiurS2KPibbzYbGJ/uhjm9hEZZUwRZLp0KH9Gvm+Wy1eJT3jlGRrG4r8IaVicRyQCGQ
	11cs4wdxove+UFdfmbmWhmrSnS3QtWtYKIz8Me1RMOVZH28bwN9zVLSzPsVyhkdW9tf3
	O+qA==
X-Gm-Message-State: ALoCoQmOdftNL9LR7NIs/JGeShE+n7G61ZzxT8dSBk3P7wus6CUbZ8zWXTsl2xaJPTBUfvVOmJjy
X-Received: by 10.107.11.154 with SMTP id 26mr2690367iol.105.1442463840762;
	Wed, 16 Sep 2015 21:24:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.135.104 with HTTP; Wed, 16 Sep 2015 21:23:41 -0700 (PDT)
X-Originating-IP: [66.130.36.70]
In-Reply-To: <4E3B7469-1018-4649-8DF1-6597F82774F1@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>
	<CAOG=w-tuFtX2t+0FVfkoObw_a9-7j4LwX87YJU1n7adYu=DMdQ@mail.gmail.com>
	<CADJgMzsPrg7VhTQC8aCvcQ3yAN8rtt+Qv_yfrCKMqOALpGPVyg@mail.gmail.com>
	<4E3B7469-1018-4649-8DF1-6597F82774F1@gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 17 Sep 2015 00:23:41 -0400
Message-ID: <CAOG=w-u2b9BTNyAxdzEnOxazr1Gc_Yrf5CxCfrjeJi39NV=cgQ@mail.gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/alternative; boundary=001a113f7e7cd4a547051fe9c866
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: Btc Drak via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.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, 17 Sep 2015 04:24:02 -0000

--001a113f7e7cd4a547051fe9c866
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Eric, that would be, I think, my sequencenumbers2 branch in which nSequence
is an explicit relative lock-time field (unless the most significant bit is
set). That has absolutely clear semantics. You should comment on #6312
where this is being discussed.

On Wed, Sep 16, 2015 at 7:23 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:

> 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=3D=
1
>>> means 1 block relative lock-height. nSequence=3DLOCKTIME_THRESHOLD mean=
s 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 relativ=
e
>>> lock times using blocks as units, and saves 12 low-order bits for futur=
e
>>> 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 uni=
t
>>>> of measurement.
>>>>
>>>>  * 1 year of time with 1-second granularity requires 25 bits. However
>>>> since blocks occur at approximately 10 minute intervals on average, ha=
ving
>>>> a relative lock-time significantly less than this interval doesn't mak=
e
>>>> much sense. A granularity of 256 seconds would be greater than the Nyq=
uist
>>>> 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 on=
ly
>>>> 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 h=
aving
>>>> trouble thinking of any use case that would require more than a year o=
f
>>>> lock-time. Can anyone else think of a use case that requires >1yr rela=
tive
>>>> lock-time?
>>>>
>>>> TL;DR
>>>>
>>>> On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <mark@friedenbach.or=
g
>>>> > wrote:
>>>>
>>>>> A power of 2 would be far more efficient here. The key question is ho=
w
>>>>> long of a relative block time do you need? Figure out what the maximu=
m
>>>>> 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
>>>>>> <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.
>

--001a113f7e7cd4a547051fe9c866
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Eric, that would be, I think, my sequencenumbers2 branch i=
n which nSequence is an explicit relative lock-time field (unless the most =
significant bit is set). That has absolutely clear semantics. You should co=
mment on #6312 where this is being discussed.<br></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Wed, Sep 16, 2015 at 7:23 PM, Eric=
 Lombrozo <span dir=3D"ltr">&lt;<a href=3D"mailto:elombrozo@gmail.com" targ=
et=3D"_blank">elombrozo@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div>I&#39;d rather replace the whole nSequence thing with a=
n explicit relative locktime with clear semantics...but I&#39;m not going t=
o fight this one too much.<div><div class=3D"h5"><br><br><div class=3D"gmai=
l_quote">On September 16, 2015 6:40:06 PM EDT, Btc Drak via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
<div dir=3D"ltr">Where do we stand now on which=C2=A0sequencenumbers variat=
ion to use? We really should make a decision now.</div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Fri, Aug 28, 2015 at 12:32 AM, Mar=
k Friedenbach via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div><div>So I&#39;ve created 2 new repositories with changed =
rules regarding sequencenumbers:<br><br><a href=3D"https://github.com/maaku=
/bitcoin/tree/sequencenumbers2" target=3D"_blank">https://github.com/maaku/=
bitcoin/tree/sequencenumbers2</a><br><br></div>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&gt;=3D0x80000000 (most
significant bit set) is not interpreted as a relative lock-time.<br><br><a =
href=3D"https://github.com/maaku/bitcoin/tree/sequencenumbers3" target=3D"_=
blank">https://github.com/maaku/bitcoin/tree/sequencenumbers3</a><br><br></=
div>This repository not only inverts the sequence number, but also interpre=
ts 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 bit=
s for future use without second-level granularity. More bits could be recov=
ered from time-based locktimes by choosing a higher granularity (a soft-for=
k change if done correctly).<br></div><div><div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Tue, Aug 25, 2015 at 3:08 PM, Mark Friede=
nbach <span dir=3D"ltr">&lt;<a href=3D"mailto:mark@friedenbach.org" target=
=3D"_blank">mark@friedenbach.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div>To follow up on this, let&#39;s sa=
y that you want to be able to have up to 1 year relative lock-times. This c=
hoice is somewhat arbitrary and what I would like some input on, but I&#39;=
ll come back to this point.<br><br></div><div>=C2=A0* 1 bit is necessary to=
 enable/disable relative lock-time.<br></div><div><br></div><div>=C2=A0* 1 =
bit is necessary to indicate whether seconds vs blocks as the unit of measu=
rement.<br><br></div><div>=C2=A0* 1 year of time with 1-second granularity =
requires 25 bits. However since blocks occur at approximately 10 minute int=
ervals on average, having a relative lock-time significantly less than this=
 interval doesn&#39;t make much sense. A granularity of 256 seconds would b=
e greater than the Nyquist frequency and requires only 17 bits.<br><br></di=
v><div>=C2=A0* 1 year of blocks with 1-block granularity requires 16 bits.<=
br></div><div><br></div>So time-based relative lock time requires about 19 =
bits, and block-based relative lock-time requires about 18 bits. That leave=
s 13 or 14 bits for other uses.<br><br></div><div>Assuming a maximum of 1-y=
ear 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 th=
at would require more than a year of lock-time. Can anyone else think of a =
use case that requires &gt;1yr relative lock-time?<br></div><div><br></div>=
TL;DR <br></div><div><div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach <span dir=3D"ltr=
">&lt;<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friede=
nbach.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-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&#39;t know what that would be, any ideas?) 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, &quot;Jorge Tim=C3=B3n&=
quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the<br>
&gt; discussion has any thought been given to represent one block with more=
<br>
&gt; than one increment?=C2=A0 This would leave additional space for future=
<br>
&gt; signaling, or allow, for example, higher resolution numbers for a<br>
&gt; sharechain commitement.<br>
<br>
No, I don&#39;t think anybody thought about this. I just explained this to<=
br>
Pieter using &quot;for example, 10 instead of 1&quot;.<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>
</div></div><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>
<br></blockquote></div><br></div>
<p style=3D"margin-top:2.5em;margin-bottom:1em;border-bottom:1px solid #000=
"></p><pre><hr><br>bitcoin-dev mailing list<br><a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.org</a><br><a href=3D"https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br></pre></blockquote></div><br></div></div><spa=
n class=3D"HOEnZb"><font color=3D"#888888">
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</font>=
</span></div></blockquote></div><br></div>

--001a113f7e7cd4a547051fe9c866--