diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2015-09-16 22:27:33 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-16 20:27:36 +0000 |
| commit | 3cade97b8e1fb76311522759dcc8aff644a07f95 (patch) | |
| tree | 2fd999a670efcbce8c92124085f98c3429cd1ad2 /c0 | |
| parent | 4f23b1064dc8a686b80904a784f708807a2379f9 (diff) | |
| download | pi-bitcoindev-3cade97b8e1fb76311522759dcc8aff644a07f95.tar.gz pi-bitcoindev-3cade97b8e1fb76311522759dcc8aff644a07f95.zip | |
Re: [bitcoin-dev] [BIP Proposal] Version bits with timeout and delay.
Diffstat (limited to 'c0')
| -rw-r--r-- | c0/92f15da637cb5b51ed39db5093ae0cf8e62ed3 | 277 |
1 files changed, 277 insertions, 0 deletions
diff --git a/c0/92f15da637cb5b51ed39db5093ae0cf8e62ed3 b/c0/92f15da637cb5b51ed39db5093ae0cf8e62ed3 new file mode 100644 index 000000000..35c0628fb --- /dev/null +++ b/c0/92f15da637cb5b51ed39db5093ae0cf8e62ed3 @@ -0,0 +1,277 @@ +Return-Path: <jtimon@jtimon.cc> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 96F981434 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 16 Sep 2015 20:27:35 +0000 (UTC) +Received: by wiclk2 with SMTP id lk2so89816752wic.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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> + <CAE-z3OWLteNyBWuYSkYLZNteOGjDch_fViOV2kpWCaZkXsbu4w@mail.gmail.com> + <87r3lyjewl.fsf@rustcorp.com.au> +Date: Wed, 16 Sep 2015 22:27:33 +0200 +Message-ID: <CABm2gDqh=Dv2Ygctg+jEt61N_nJDRBMqdZypSPtmfM2QrY4AYQ@mail.gmail.com> +From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> +To: Rusty Russell <rusty@rustcorp.com.au> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <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: 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 <bitcoin-dev@lists.linuxfoundation.org> +> 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 + +<p dir=3D"ltr">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.</p> +<div class=3D"gmail_quote">On Sep 16, 2015 4:20 PM, "Rusty Russell via= + bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.= +org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attrib= +ution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= +left:1px #ccc solid;padding-left:1ex">Tier Nolan via bitcoin-dev <<a hre= +f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxf= +oundation.org</a>><br> +writes:<br> +> On Sun, Sep 13, 2015 at 7:56 PM, Rusty Russell via bitcoin-dev <<br= +> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= +ists.linuxfoundation.org</a>> wrote:<br> +><br> +>> '''States'''<br> +>> With every softfork proposal we associate a state BState, which be= +gins<br> +>> at ''defined'', and can be ''locked-in'= +;', ''activated'',<br> +>> or ''failed''.=C2=A0 Transitions are considered af= +ter each<br> +>> retarget period.<br> +>><br> +><br> +> I think the 75% rule should be maintained.=C2=A0 It confirms that mine= +rs who are<br> +> setting the bit are actually creating blocks that meet the new rule (t= +hough<br> +> it doesn't check if they are enforcing it).<br> +<br> +I couldn't see a use for it, since partial enforcement of a soft fork i= +s<br> +pretty useless.<br> +<br> +Your point about checking that miners are actually doing it is true,<br> +though all stuff being forked in in future will be nonstandard AFAICT.<br> +<br> +I bias towards simplicity for this.<br> +<br> +> What is the reason for aligning the updated to the difficulty window?<= +br> +<br> +Miners already have that date in their calendar, so prefer to anchor to<br> +that.<br> +<br> +> *defined*<br> +> Miners set bit<br> +> If 75% of blocks of last 2016 have bit set, goto tentative<br> +><br> +><br> +> *tentative*<br> +> Miners set bit<br> +> Reject blocks that have bit set that don't follow new rule<br> +> If 95% of blocks of last 2016 have bit set, goto locked-in<br> +><br> +><br> +> *locked-in*<br> +><br> +> Point of no return<br> +> Miners still set bit<br> +> Reject blocks that have bit set that don't follow new rule<br> +> After 2016 blocks goto notice<br> +<br> +OK, *that* variant makes perfect sense, and is no more complex, AFAICT.<br> +<br> +So, there's two weeks to detect bad implementations, then you everyone<= +br> +stops setting the bit, for later reuse by another BIP.<br> +<br> +> I think counting in blocks is easier to be exact here.<br> +<br> +Easier for code, but harder for BIP authors.<br> +<br> +> If two bits were allocated per proposal, then miners could vote agains= +t<br> +> forks to recover the bits.=C2=A0 If 25% of the miners vote against, th= +en that<br> +> kills it.<br> +<br> +You need a timeout: an ancient (non-mining, thus undetectable) node<br> +should never fork itself off the network because someone reused a failed<br= +> +BIP bit.<br> +<br> +> In the rationale, it would be useful to discuss effects on SPV clients= + and<br> +> buggy miners.<br> +><br> +> SPV clients should be recommended to actually monitor the version fiel= +d.<br> +<br> +SPV clients don't experience a security change when a soft fork occurs?= +<br> +They're already trusting miners.<br> +<br> +Greg pointed out that soft forks tend to get accompanied by block forks<br> +across activation, but SPV clients should *definitely* be taking those<br> +into account whenever they happen, right?<br> +<br> +Thanks!<br> +Rusty.<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> +</blockquote></div> + +--089e01160002f15a0a051fe3205c-- + |