Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2257D948 for ; 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 ; Thu, 15 Oct 2015 16:41:58 +0000 (UTC) Received: by iofl186 with SMTP id l186so96234395iof.2 for ; 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: References: <20151003143056.GA27942@muck> <87lhbgn4fa.fsf@rustcorp.com.au> <20151008174120.GA9291@muck> <87pp0okeip.fsf@rustcorp.com.au> Date: Thu, 15 Oct 2015 12:41:57 -0400 Message-ID: From: Alex Morcos To: Adam Back 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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 > > 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 > >> wrote: > >>> > >>> Peter Todd writes: > >>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote: > >>> >> Peter Todd via bitcoin-dev > >>> >> 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
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@cyphers= pace.org> wrote:
Does tha= t pre-judge that block interval would never change from
10mins?=C2=A0 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> wro= te:
> Alex,
>
> I am sorry for not communicating more clearly. Mark and I discussed yo= ur
> concerns from the last meeting and he made the change. The BIP text st= ill
> needs to be updated, but the discussed change was added to the PR, alb= eit
> 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. >
>=C2=A0 =C2=A0 =C2=A0/* If CTxIn::nSequence encodes a relative lock-time= , this mask is
>=C2=A0 =C2=A0 =C2=A0 * applied to extract that lock-time from the seque= nce field. */
>=C2=A0 =C2=A0 =C2=A0static const uint32_t SEQUENCE_LOCKTIME_MASK =3D 0x= 0000ffff;
>
>=C2=A0 =C2=A0 =C2=A0/* In order to use the same number of bits to encod= e roughly the
>=C2=A0 =C2=A0 =C2=A0 * same wall-clock duration, and because blocks are= naturally
>=C2=A0 =C2=A0 =C2=A0 * limited to occur every 600s on average, the mini= mum granularity
>=C2=A0 =C2=A0 =C2=A0 * for time-based relative lock-time is fixed at 51= 2 seconds.
>=C2=A0 =C2=A0 =C2=A0 * Converting from CTxIn::nSequence to seconds is p= erformed by
>=C2=A0 =C2=A0 =C2=A0 * multiplying by 512 =3D 2^9, or equivalently shif= ting up by
>=C2=A0 =C2=A0 =C2=A0 * 9 bits. */
>=C2=A0 =C2=A0 =C2=A0static const int SEQUENCE_LOCKTIME_GRANULARITY =3D = 9;
>
> I am also much happier with this last tightening up of the specificati= on
> because it removes ambiguity. 512s granularity makes sense within the<= br> > 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-d= ev@lists.linuxfoundation.org> wrote:
>>
>> Mark,
>>
>> You seemed interested in changing BIP 68 to use 16 bits for sequen= ce
>> number in both the block and time versions, making time based sequ= ence
>> 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 p= erhaps
>> people can hold off on review until things are finalized.
>>
>> I'd cast my "vote" against BIP 68 without this chang= e, 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
>> <bitco= in-dev@lists.linuxfoundation.org> wrote:
>>>
>>> Peter Todd <pete@pete= rtodd.org> writes:
>>> > On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell w= rote:
>>> >> 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) proposa= l 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 bl= ocksize voting
>>> > with nSequence.
>>>
>>> Excellent, thanks!=C2=A0 It's good to have such ideas as a= compass.=C2=A0 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.= =C2=A0 We would
>>> have to then split between nLocktime (if available) and multip= le
>>> 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 (m= empool
>>> would enforce it always).
>>>
>>> Cheers,
>>> Rusty.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitco= in-dev@lists.linuxfoundation.org
>>> https://lists.linuxfounda= tion.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>

--001a113ff20e7d53450522275b71--