path: root/ae/849dc28c9974112b36874c197300206b8a1aec

Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2257D948
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Oct 2015 16:41:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f173.google.com (mail-io0-f173.google.com
	[209.85.223.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2502F8C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Oct 2015 16:41:58 +0000 (UTC)
Received: by iofl186 with SMTP id l186so96234395iof.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Oct 2015 09:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=hxvt9fkKRHjpBDCiZBa47lmL2QyrROK3sJ4aQaVWrok=;
	b=ZpDXsFJ1vvu7quge/dXTUIP+E+WVsUoLGJZwVj3ZLOA2to7H3oiwQ4XWfSHMaKQlVO
	KM3O45xziZjdk1FxzF7z+lVaNQbcwiMKFKp7Ua6vD+qSyB/yiu2ChgbVwzjgyxPEj8uZ
	yT3dQyvgJ8FIOMeLXJVYGjo6tzOFbLwIUCT/cz7as/0MEoqyjvR8RTfDU4Hy+9WtkH6Y
	ADVZ29EQylxigYxGoPk3J0Tuw/VtQ6c31XI1dufjjK9wXYvFr68XLT47Y/1Uyq4LWLeT
	oGkWyLIxZZGQ5/nCybPEz69LJrt6xRKxYYbCnHrHpWGFsKrM1/iIhKdTzpp3gVEeaRDO
	a8uw==
MIME-Version: 1.0
X-Received: by 10.107.25.71 with SMTP id 68mr7916653ioz.46.1444927317559; Thu,
	15 Oct 2015 09:41:57 -0700 (PDT)
Received: by 10.64.25.80 with HTTP; Thu, 15 Oct 2015 09:41:57 -0700 (PDT)
In-Reply-To: <CALqxMTEG-LVRA9VtYOzNMBUCK_M78Fx6ivVY9NZ8B2rfom5oKA@mail.gmail.com>
References: <20151003143056.GA27942@muck> <87lhbgn4fa.fsf@rustcorp.com.au>
	<20151008174120.GA9291@muck> <87pp0okeip.fsf@rustcorp.com.au>
	<CAPWm=eUR1fo4iVX=-J7mO34LvT6akRy5=Cxjn7j64PBn+A_oGQ@mail.gmail.com>
	<CADJgMzsvdG2iE=FhYrgKve_JxtMjFVOS4Gx-0Q8GnqDYF_-qOw@mail.gmail.com>
	<CALqxMTEG-LVRA9VtYOzNMBUCK_M78Fx6ivVY9NZ8B2rfom5oKA@mail.gmail.com>
Date: Thu, 15 Oct 2015 12:41:57 -0400
Message-ID: <CAPWm=eVRespS+FDm4zpnBSi7-UWBV7pE1x+=FubADQfVwEK9RA@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a113ff20e7d53450522275b71
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to
 motivate the change
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, 15 Oct 2015 16:41:59 -0000

--001a113ff20e7d53450522275b71
Content-Type: text/plain; charset=UTF-8

Adam,

The remaining 14 bits can be used to soft fork in finer granularity in the
future.

Alex


On Thu, Oct 15, 2015 at 12:37 PM, Adam Back <adam@cypherspace.org> wrote:

> Does that pre-judge that block interval would never change from
> 10mins?  Eg say with IBLT or fountain codes etc and security arguments
> for the current limitations of them are found, such that orphan rates
> can remain low in a decentralised way with 1min blocks, then the
> locktime granularity would be coarse relative to the block interval
> (with 512s locktime granularity.
>
> Adam
>
> On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Alex,
> >
> > I am sorry for not communicating more clearly. Mark and I discussed your
> > concerns from the last meeting and he made the change. The BIP text still
> > needs to be updated, but the discussed change was added to the PR, albeit
> > squashed making it more non-obvious. BIP68 now explicitly uses 16 bits
> with
> > a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and
> > SEQUENCE_LOCKTIME_GRANULARITY in the PR
> > https://github.com/bitcoin/bitcoin/pull/6312.
> >
> >     /* If CTxIn::nSequence encodes a relative lock-time, this mask is
> >      * applied to extract that lock-time from the sequence field. */
> >     static const uint32_t SEQUENCE_LOCKTIME_MASK = 0x0000ffff;
> >
> >     /* In order to use the same number of bits to encode roughly the
> >      * same wall-clock duration, and because blocks are naturally
> >      * limited to occur every 600s on average, the minimum granularity
> >      * for time-based relative lock-time is fixed at 512 seconds.
> >      * Converting from CTxIn::nSequence to seconds is performed by
> >      * multiplying by 512 = 2^9, or equivalently shifting up by
> >      * 9 bits. */
> >     static const int SEQUENCE_LOCKTIME_GRANULARITY = 9;
> >
> > I am also much happier with this last tightening up of the specification
> > because it removes ambiguity. 512s granularity makes sense within the
> > context of the 10 minute block target.
> >
> > Thank you for spending so much time carefully considering this BIP and
> > reference implementation and please let me know if there there are any
> > remaining nits so we can get those addressed.
> >
> >
> >
> >
> >
> > On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Mark,
> >>
> >> You seemed interested in changing BIP 68 to use 16 bits for sequence
> >> number in both the block and time versions, making time based sequence
> >> numbers have a resolution of 512 seconds.
> >>
> >> I'm in favor of this approach because it leaves aside 14 bits for
> further
> >> soft forks within the semantics of BIP 68.
> >>
> >> It would be nice to know if you're planning this change, and perhaps
> >> people can hold off on review until things are finalized.
> >>
> >> I'd cast my "vote" against BIP 68 without this change, but am also open
> to
> >> being convinced otherwise.
> >>
> >> What are other peoples opinions on this?
> >>
> >> On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>>
> >>> Peter Todd <pete@petertodd.org> writes:
> >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> >>> >> Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> >>> >> writes:
> >>> >> > However I don't think we've done a good job showing why we need to
> >>> >> > implement this feature via nSequence.
> >>> >>
> >>> >> It could be implemented in other ways, but nSequence is the neatest
> >>> >> and
> >>> >> most straightforward I've seen.
> >>> >>
> >>> >> - I'm not aware of any other (even vague) proposal for its use?
> >>> >> Enlighten?
> >>> >
> >>> > There's three that immediately come to mind:
> >>> >
> >>> > Gregory Maxwell has proposed it as a way of discouraging miners from
> >>> > reorging chains, by including some of the low-order bits of a
> previous
> >>> > block header in nSequence.
> >>> >
> >>> > A few people have proposed implementing proof-of-stake blocksize
> voting
> >>> > with nSequence.
> >>>
> >>> Excellent, thanks!  It's good to have such ideas as a compass.  PoS
> >>> voting seems like it won't be a problem in 5 bits.
> >>>
> >>> The "prevbits" idea would want more bits; naively 64 would be good, but
> >>> I think there are some tricks we can use to make 32 work OK.  We would
> >>> have to then split between nLocktime (if available) and multiple
> >>> nSequence fields, and it would weaken it for some txs.
> >>>
> >>> There is one easy solution: change the BIP wording from:
> >>>
> >>> -For transactions with an nVersion of 2 or greater,
> >>> +For transactions with an nVersion of 2,
> >>>
> >>> And on every tx bump, we decide whether to keep this scheme (mempool
> >>> would enforce it always).
> >>>
> >>> Cheers,
> >>> Rusty.
> >>> _______________________________________________
> >>> 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
> >
>

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

<div dir=3D"ltr">Adam,<div><br></div><div>The remaining 14 bits can be used=
 to soft fork in finer granularity in the future.</div><div><br></div><div>=
Alex</div><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">On Thu, Oct 15, 2015 at 12:37 PM, Adam Back <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cyphers=
pace.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">Does tha=
t pre-judge that block interval would never change from<br>
10mins?=C2=A0 Eg say with IBLT or fountain codes etc and security arguments=
<br>
for the current limitations of them are found, such that orphan rates<br>
can remain low in a decentralised way with 1min blocks, then the<br>
locktime granularity would be coarse relative to the block interval<br>
(with 512s locktime granularity.<br>
<br>
Adam<br>
<br>
On 15 October 2015 at 18:27, Btc Drak via bitcoin-dev<br>
<div class=3D"HOEnZb"><div class=3D"h5">&lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wro=
te:<br>
&gt; Alex,<br>
&gt;<br>
&gt; I am sorry for not communicating more clearly. Mark and I discussed yo=
ur<br>
&gt; concerns from the last meeting and he made the change. The BIP text st=
ill<br>
&gt; needs to be updated, but the discussed change was added to the PR, alb=
eit<br>
&gt; squashed making it more non-obvious. BIP68 now explicitly uses 16 bits=
 with<br>
&gt; a bitmask. Please see the use of SEQUENCE_LOCKTIME_MASK and<br>
&gt; SEQUENCE_LOCKTIME_GRANULARITY in the PR<br>
&gt; <a href=3D"https://github.com/bitcoin/bitcoin/pull/6312" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6312</a>.<b=
r>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0/* If CTxIn::nSequence encodes a relative lock-time=
, this mask is<br>
&gt;=C2=A0 =C2=A0 =C2=A0 * applied to extract that lock-time from the seque=
nce field. */<br>
&gt;=C2=A0 =C2=A0 =C2=A0static const uint32_t SEQUENCE_LOCKTIME_MASK =3D 0x=
0000ffff;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0/* In order to use the same number of bits to encod=
e roughly the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 * same wall-clock duration, and because blocks are=
 naturally<br>
&gt;=C2=A0 =C2=A0 =C2=A0 * limited to occur every 600s on average, the mini=
mum granularity<br>
&gt;=C2=A0 =C2=A0 =C2=A0 * for time-based relative lock-time is fixed at 51=
2 seconds.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 * Converting from CTxIn::nSequence to seconds is p=
erformed by<br>
&gt;=C2=A0 =C2=A0 =C2=A0 * multiplying by 512 =3D 2^9, or equivalently shif=
ting up by<br>
&gt;=C2=A0 =C2=A0 =C2=A0 * 9 bits. */<br>
&gt;=C2=A0 =C2=A0 =C2=A0static const int SEQUENCE_LOCKTIME_GRANULARITY =3D =
9;<br>
&gt;<br>
&gt; I am also much happier with this last tightening up of the specificati=
on<br>
&gt; because it removes ambiguity. 512s granularity makes sense within the<=
br>
&gt; context of the 10 minute block target.<br>
&gt;<br>
&gt; Thank you for spending so much time carefully considering this BIP and=
<br>
&gt; reference implementation and please let me know if there there are any=
<br>
&gt; remaining nits so we can get those addressed.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Mark,<br>
&gt;&gt;<br>
&gt;&gt; You seemed interested in changing BIP 68 to use 16 bits for sequen=
ce<br>
&gt;&gt; number in both the block and time versions, making time based sequ=
ence<br>
&gt;&gt; numbers have a resolution of 512 seconds.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m in favor of this approach because it leaves aside 14 bits =
for further<br>
&gt;&gt; soft forks within the semantics of BIP 68.<br>
&gt;&gt;<br>
&gt;&gt; It would be nice to know if you&#39;re planning this change, and p=
erhaps<br>
&gt;&gt; people can hold off on review until things are finalized.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;d cast my &quot;vote&quot; against BIP 68 without this chang=
e, but am also open to<br>
&gt;&gt; being convinced otherwise.<br>
&gt;&gt;<br>
&gt;&gt; What are other peoples opinions on this?<br>
&gt;&gt;<br>
&gt;&gt; On Thu, Oct 8, 2015 at 9:38 PM, Rusty Russell via bitcoin-dev<br>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@pete=
rtodd.org</a>&gt; writes:<br>
&gt;&gt;&gt; &gt; On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell w=
rote:<br>
&gt;&gt;&gt; &gt;&gt; Peter Todd via bitcoin-dev &lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a=
>&gt;<br>
&gt;&gt;&gt; &gt;&gt; writes:<br>
&gt;&gt;&gt; &gt;&gt; &gt; However I don&#39;t think we&#39;ve done a good =
job showing why we need to<br>
&gt;&gt;&gt; &gt;&gt; &gt; implement this feature via nSequence.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; It could be implemented in other ways, but nSequence =
is the neatest<br>
&gt;&gt;&gt; &gt;&gt; and<br>
&gt;&gt;&gt; &gt;&gt; most straightforward I&#39;ve seen.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; - I&#39;m not aware of any other (even vague) proposa=
l for its use?<br>
&gt;&gt;&gt; &gt;&gt; Enlighten?<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; There&#39;s three that immediately come to mind:<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; Gregory Maxwell has proposed it as a way of discouraging =
miners from<br>
&gt;&gt;&gt; &gt; reorging chains, by including some of the low-order bits =
of a previous<br>
&gt;&gt;&gt; &gt; block header in nSequence.<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; A few people have proposed implementing proof-of-stake bl=
ocksize voting<br>
&gt;&gt;&gt; &gt; with nSequence.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Excellent, thanks!=C2=A0 It&#39;s good to have such ideas as a=
 compass.=C2=A0 PoS<br>
&gt;&gt;&gt; voting seems like it won&#39;t be a problem in 5 bits.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The &quot;prevbits&quot; idea would want more bits; naively 64=
 would be good, but<br>
&gt;&gt;&gt; I think there are some tricks we can use to make 32 work OK.=
=C2=A0 We would<br>
&gt;&gt;&gt; have to then split between nLocktime (if available) and multip=
le<br>
&gt;&gt;&gt; nSequence fields, and it would weaken it for some txs.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; There is one easy solution: change the BIP wording from:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -For transactions with an nVersion of 2 or greater,<br>
&gt;&gt;&gt; +For transactions with an nVersion of 2,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; And on every tx bump, we decide whether to keep this scheme (m=
empool<br>
&gt;&gt;&gt; would enforce it always).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Cheers,<br>
&gt;&gt;&gt; Rusty.<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a><br>
&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda=
tion.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
</div></div></blockquote></div><br></div>

--001a113ff20e7d53450522275b71--