Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 96F981434 for ; Wed, 16 Sep 2015 20:27:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A7E7D1E6 for ; Wed, 16 Sep 2015 20:27:35 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so89816752wic.0 for ; Wed, 16 Sep 2015 13:27:34 -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:date :message-id:subject:from:to:cc:content-type; bh=AJrsAb6iI9T3xjgHmFKhhmONaeLmjALKOdmehFn8RIY=; b=QtxJMm4IBU0UGoHKtY7hGTfl4xb+UwFKc86z+HVcui/T/wdojmWmkusz0xzFujlwfp yjAkHN+GqBKc3aiLSo3ku2mzaiG5iL+Zvr4vccFZLaEoNjRHEvW/kHcF1ARslSyJrkyK jMnJUqr866dapXLp6kiuG3NtMFxnC6wDCz/0+XvfBlAszhwxNOn3oNx5I3PcVLAT8TPA IEzhmaoPqNDsQPVg4/sLxyjYqc9EfRD8/3Izfs8Go5/SlpWqLk7m5qwlXTVcH7Q1WHGY uVDr/dBPrUSwNT3tD6zw/BqYZf/wXcSQvmTQ5T8+5OfD+x/0Y0UkDE2wYntAjQPDKogg 8Ztw== X-Gm-Message-State: ALoCoQldbddrk2okTd0ZfHqVfpctcaWznEnDftaut9a//YI+cTAUEe0CjElXWKbvCZVI7pICmC6G MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr55688845wjb.133.1442435254263; Wed, 16 Sep 2015 13:27:34 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Wed, 16 Sep 2015 13:27:33 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Wed, 16 Sep 2015 13:27:33 -0700 (PDT) In-Reply-To: <87r3lyjewl.fsf@rustcorp.com.au> References: <87mvwqb132.fsf@rustcorp.com.au> <87r3lyjewl.fsf@rustcorp.com.au> Date: Wed, 16 Sep 2015 22:27:33 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Rusty Russell Content-Type: multipart/alternative; boundary=089e01160002f15a0a051fe3205c 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 Proposal] Version bits with timeout and delay. 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: Wed, 16 Sep 2015 20:27:36 -0000 --089e01160002f15a0a051fe3205c Content-Type: text/plain; charset=UTF-8 For enforcing new restrictions on your own blocks (thus at the policy level, not consensus) you don't need to wait for 75%. You can do it from the start (this way all miners setting the bit will enforce the new restrictions. On Sep 16, 2015 4:20 PM, "Rusty Russell via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Tier Nolan via bitcoin-dev > writes: > > On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > >> '''States''' > >> With every softfork proposal we associate a state BState, which begins > >> at ''defined'', and can be ''locked-in'', ''activated'', > >> or ''failed''. Transitions are considered after each > >> retarget period. > >> > > > > I think the 75% rule should be maintained. It confirms that miners who > are > > setting the bit are actually creating blocks that meet the new rule > (though > > it doesn't check if they are enforcing it). > > I couldn't see a use for it, since partial enforcement of a soft fork is > pretty useless. > > Your point about checking that miners are actually doing it is true, > though all stuff being forked in in future will be nonstandard AFAICT. > > I bias towards simplicity for this. > > > What is the reason for aligning the updated to the difficulty window? > > Miners already have that date in their calendar, so prefer to anchor to > that. > > > *defined* > > Miners set bit > > If 75% of blocks of last 2016 have bit set, goto tentative > > > > > > *tentative* > > Miners set bit > > Reject blocks that have bit set that don't follow new rule > > If 95% of blocks of last 2016 have bit set, goto locked-in > > > > > > *locked-in* > > > > Point of no return > > Miners still set bit > > Reject blocks that have bit set that don't follow new rule > > After 2016 blocks goto notice > > OK, *that* variant makes perfect sense, and is no more complex, AFAICT. > > So, there's two weeks to detect bad implementations, then you everyone > stops setting the bit, for later reuse by another BIP. > > > I think counting in blocks is easier to be exact here. > > Easier for code, but harder for BIP authors. > > > If two bits were allocated per proposal, then miners could vote against > > forks to recover the bits. If 25% of the miners vote against, then that > > kills it. > > You need a timeout: an ancient (non-mining, thus undetectable) node > should never fork itself off the network because someone reused a failed > BIP bit. > > > In the rationale, it would be useful to discuss effects on SPV clients > and > > buggy miners. > > > > SPV clients should be recommended to actually monitor the version field. > > SPV clients don't experience a security change when a soft fork occurs? > They're already trusting miners. > > Greg pointed out that soft forks tend to get accompanied by block forks > across activation, but SPV clients should *definitely* be taking those > into account whenever they happen, right? > > Thanks! > Rusty. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --089e01160002f15a0a051fe3205c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

For enforcing new restrictions on your own blocks (thus at t= he policy level, not consensus) you don't need to wait for 75%. You can= do it from the start (this way all miners setting the bit will enforce the= new restrictions.

On Sep 16, 2015 4:20 PM, "Rusty Russell via= bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
Tier Nolan via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.org>
writes:
> On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev < > bitcoin-dev@l= ists.linuxfoundation.org> wrote:
>
>> '''States'''
>> With every softfork proposal we associate a state BState, which be= gins
>> at ''defined'', and can be ''locked-in'= ;', ''activated'',
>> or ''failed''.=C2=A0 Transitions are considered af= ter each
>> retarget period.
>>
>
> I think the 75% rule should be maintained.=C2=A0 It confirms that mine= rs who are
> setting the bit are actually creating blocks that meet the new rule (t= hough
> it doesn't check if they are enforcing it).

I couldn't see a use for it, since partial enforcement of a soft fork i= s
pretty useless.

Your point about checking that miners are actually doing it is true,
though all stuff being forked in in future will be nonstandard AFAICT.

I bias towards simplicity for this.

> What is the reason for aligning the updated to the difficulty window?<= br>
Miners already have that date in their calendar, so prefer to anchor to
that.

> *defined*
> Miners set bit
> If 75% of blocks of last 2016 have bit set, goto tentative
>
>
> *tentative*
> Miners set bit
> Reject blocks that have bit set that don't follow new rule
> If 95% of blocks of last 2016 have bit set, goto locked-in
>
>
> *locked-in*
>
> Point of no return
> Miners still set bit
> Reject blocks that have bit set that don't follow new rule
> After 2016 blocks goto notice

OK, *that* variant makes perfect sense, and is no more complex, AFAICT.

So, there's two weeks to detect bad implementations, then you everyone<= br> stops setting the bit, for later reuse by another BIP.

> I think counting in blocks is easier to be exact here.

Easier for code, but harder for BIP authors.

> If two bits were allocated per proposal, then miners could vote agains= t
> forks to recover the bits.=C2=A0 If 25% of the miners vote against, th= en that
> kills it.

You need a timeout: an ancient (non-mining, thus undetectable) node
should never fork itself off the network because someone reused a failed BIP bit.

> In the rationale, it would be useful to discuss effects on SPV clients= and
> buggy miners.
>
> SPV clients should be recommended to actually monitor the version fiel= d.

SPV clients don't experience a security change when a soft fork occurs?=
They're already trusting miners.

Greg pointed out that soft forks tend to get accompanied by block forks
across activation, but SPV clients should *definitely* be taking those
into account whenever they happen, right?

Thanks!
Rusty.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--089e01160002f15a0a051fe3205c--