path: root/65/b0528e86c021f98ffefd744323d2a39232281b

Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 58E9989E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Oct 2015 16:28:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com
	[209.85.220.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31F3312D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Oct 2015 16:28:04 +0000 (UTC)
Received: by qkap81 with SMTP id p81so41971715qka.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 15 Oct 2015 09:28:03 -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=+6WEUNyi5b9B7WnEIpNnXEFrJq7ogFJtXATRxitHIcQ=;
	b=zeLDJyHeTJuug5HhlatZEDy7bUnfaCVMzKzUngNRs6i/Yawb74xr8M+bncZpvKELw1
	ld43n0IcaRSAb+Nx+7DpCxw8NO2fYSbobrtSBkJ78UYA42EYRkbm09NYCPHWK5xIwOqq
	Ga8To5/aNmjl907fEf3R42ZOvnM9Zoi5r14MCh1KJRLoMY+4P1b6A+dD5iOM5asfYhVl
	fr1yYlp2zukNUIEQc0EbAA9rDCkfsLuOw0iLRL4KTpTo+G7xpumw/kzq/I4I1Rp2ht7T
	5ZT7hkuLRDH7IyzeM1aaRcie5v8NyqxxuGYDNulbSquPK8HQ8T6lWQ1ha0ad7nsEdCy5
	s3Rw==
X-Received: by 10.55.22.162 with SMTP id 34mr13613356qkw.3.1444926483255; Thu,
	15 Oct 2015 09:28:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.130.7 with HTTP; Thu, 15 Oct 2015 09:27:43 -0700 (PDT)
In-Reply-To: <CAPWm=eUR1fo4iVX=-J7mO34LvT6akRy5=Cxjn7j64PBn+A_oGQ@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>
From: Btc Drak <btcdrak@gmail.com>
Date: Thu, 15 Oct 2015 17:27:43 +0100
Message-ID: <CADJgMzsvdG2iE=FhYrgKve_JxtMjFVOS4Gx-0Q8GnqDYF_-qOw@mail.gmail.com>
To: Alex Morcos <morcos@gmail.com>
Content-Type: multipart/alternative; boundary=001a11493914c2d78e0522272933
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 <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:28:05 -0000

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

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
>
>

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

<div dir=3D"ltr">Alex,<div><br></div><div>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 discuss=
ed 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 SEQ=
UENCE_LOCKTIME_MASK and=C2=A0SEQUENCE_LOCKTIME_GRANULARITY in the PR=C2=A0<=
a href=3D"https://github.com/bitcoin/bitcoin/pull/6312">https://github.com/=
bitcoin/bitcoin/pull/6312</a>.</div><div><br></div><div><div>=C2=A0 =C2=A0 =
/* If CTxIn::nSequence encodes a relative lock-time, this mask is</div><div=
>=C2=A0 =C2=A0 =C2=A0* applied to extract that lock-time from the sequence =
field. */</div><div>=C2=A0 =C2=A0 static const uint32_t SEQUENCE_LOCKTIME_M=
ASK =3D 0x0000ffff;</div><div><br></div><div>=C2=A0 =C2=A0 /* In order to u=
se the same number of bits to encode roughly the</div><div>=C2=A0 =C2=A0 =
=C2=A0* same wall-clock duration, and because blocks are naturally</div><di=
v>=C2=A0 =C2=A0 =C2=A0* limited to occur every 600s on average, the minimum=
 granularity</div><div>=C2=A0 =C2=A0 =C2=A0* for time-based relative lock-t=
ime is fixed at 512 seconds.</div><div>=C2=A0 =C2=A0 =C2=A0* Converting fro=
m CTxIn::nSequence to seconds is performed by</div><div>=C2=A0 =C2=A0 =C2=
=A0* multiplying by 512 =3D 2^9, or equivalently shifting up by</div><div>=
=C2=A0 =C2=A0 =C2=A0* 9 bits. */</div><div>=C2=A0 =C2=A0 static const int S=
EQUENCE_LOCKTIME_GRANULARITY =3D 9;</div></div><div><br></div><div>I am als=
o 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.</div><div><br></div><div>Thank you for spending so =
much time carefully considering this BIP and reference implementation and p=
lease let me know if there there are any remaining nits so we can get those=
 addressed.=C2=A0</div><div><br></div><div><br></div><div><br></div><div><b=
r></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Thu, Oct 15, 2015 at 2:47 PM, Alex Morcos via bitcoin-dev <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">Mark,=C2=A0<div><br><div>You seeme=
d 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 reso=
lution of 512 seconds.</div></div><div><br></div><div>I&#39;m in favor of t=
his approach because it leaves aside 14 bits for further soft forks within =
the semantics of BIP 68. =C2=A0</div><div><br></div><div>It would be nice t=
o know if you&#39;re planning this change, and perhaps people can hold off =
on review until things are finalized.</div><div><br></div><div>I&#39;d cast=
 my &quot;vote&quot; against BIP 68 without this change, but am also open t=
o being convinced otherwise.</div><div><br></div><div>What are other people=
s opinions on this?</div></div><div class=3D"HOEnZb"><div class=3D"h5"><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Oct 8, 2015 a=
t 9:38 PM, Rusty Russell via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><span>Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org" target=3D=
"_blank">pete@petertodd.org</a>&gt; writes:<br>
&gt; On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:<br>
&gt;&gt; Peter Todd via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a>&gt;<br>
&gt;&gt; writes:<br>
&gt;&gt; &gt; However I don&#39;t think we&#39;ve done a good job showing w=
hy we need to<br>
&gt;&gt; &gt; implement this feature via nSequence.<br>
&gt;&gt;<br>
&gt;&gt; It could be implemented in other ways, but nSequence is the neates=
t and<br>
&gt;&gt; most straightforward I&#39;ve seen.<br>
&gt;&gt;<br>
&gt;&gt; - I&#39;m not aware of any other (even vague) proposal for its use=
?=C2=A0 Enlighten?<br>
&gt;<br>
&gt; There&#39;s three that immediately come to mind:<br>
&gt;<br>
&gt; Gregory Maxwell has proposed it as a way of discouraging miners from<b=
r>
&gt; reorging chains, by including some of the low-order bits of a previous=
<br>
&gt; block header in nSequence.<br>
&gt;<br>
&gt; A few people have proposed implementing proof-of-stake blocksize votin=
g<br>
&gt; with nSequence.<br>
<br>
</span>Excellent, thanks!=C2=A0 It&#39;s good to have such ideas as a compa=
ss.=C2=A0 PoS<br>
voting seems like it won&#39;t be a problem in 5 bits.<br>
<br>
The &quot;prevbits&quot; idea would want more bits; naively 64 would be goo=
d, but<br>
I think there are some tricks we can use to make 32 work OK.=C2=A0 We would=
<br>
have to then split between nLocktime (if available) and multiple<br>
nSequence fields, and it would weaken it for some txs.<br>
<br>
There is one easy solution: change the BIP wording from:<br>
<br>
-For transactions with an nVersion of 2 or greater,<br>
+For transactions with an nVersion of 2,<br>
<br>
And on every tx bump, we decide whether to keep this scheme (mempool<br>
would enforce it always).<br>
<div><div><br>
Cheers,<br>
Rusty.<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>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>

--001a11493914c2d78e0522272933--