Return-Path: <gavinandresen@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 95285DC0 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 23 Sep 2015 19:01:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A68DC2A0 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 23 Sep 2015 19:01:57 +0000 (UTC) Received: by lahh2 with SMTP id h2so38195915lah.0 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 23 Sep 2015 12:01:55 -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=iVjOaUaazJYfVWXCUIF3qlU/s5GXc2w+BvbwRN2PnBc=; b=QQCcJvVi9iIQ2pvAD3Ww3PsFr4tSIwBmMIpBV97mV3g0FvUmQQSiBExd8KLD+mfq41 /y1RuCmB9SnHHphyTxBuiegmXDNgH6MHf25rW6/OQ8lKKmJHnysG+TVEy5my9SyJC7ux cbvX+Om+R4u/YcKb7F07u8kvk7N2jr0WZN5IJAmeK2H9mVQcVAycY/bYNgaXW6eOskb6 XxxOZm+xgNrYmWewZRBdmssrHenPDjuyj9AYDeofghxnFLrfzLxyeFNV4poOcuDunv/u qzz6SMhxDUmxgX10jCXFVPNiyvM2WRgqyrBcAuIlwp6qu/sKDCxFyQq8wkB/3rOqgfdK S9tg== MIME-Version: 1.0 X-Received: by 10.152.5.233 with SMTP id v9mr12216685lav.65.1443034915674; Wed, 23 Sep 2015 12:01:55 -0700 (PDT) Received: by 10.25.200.214 with HTTP; Wed, 23 Sep 2015 12:01:55 -0700 (PDT) In-Reply-To: <5602F075.4000102@thinlink.com> References: <87mvwqb132.fsf@rustcorp.com.au> <5602F075.4000102@thinlink.com> Date: Wed, 23 Sep 2015 15:01:55 -0400 Message-ID: <CABsx9T3pFAbtOv78uwaoToHWRXQGwmHA_h8KR89X2HLxiose5g@mail.gmail.com> From: Gavin Andresen <gavinandresen@gmail.com> To: Tom Harding <tomh@thinlink.com> Content-Type: multipart/alternative; boundary=089e013d0f5a8c1fbe05206ebf59 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] [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, 23 Sep 2015 19:01:58 -0000 --089e013d0f5a8c1fbe05206ebf59 Content-Type: text/plain; charset=UTF-8 I say keep it simple. If the 75% threshold is hit, then support suddenly drops off below 50%, "meh" -- there will be a big ruckus, everybody will freak out, and miners will refuse to build big blocks because they'll worry that they'll get orphaned. Adding more complexity for a case that ain't gonna happen (and isn't a disaster if it does) is a mistake, in my humble opinion. On Wed, Sep 23, 2015 at 2:33 PM, Tom Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote: > >> '''Success: Activation Delay''' >> The consensus rules related to ''locked-in'' soft fork will be enforced in >> the second retarget period; ie. there is a one retarget period in >> which the remaining 5% can upgrade. At the that activation block and >> after, the bit B may be reused for a different soft fork. >> >> > Rather than a simple one-period delay, should there be a one-period > "burn-in" to show sustained support of the threshold? During this period, > support must continuously remain above the threshold. Any lapse resets to > inactivated state. > > With a simple delay, you can have the embarrassing situation where support > falls off during the delay period and there is far below threshold support > just moments prior to enforcement, but enforcement happens anyway. > > BIP 101 has this problem too. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- -- Gavin Andresen --089e013d0f5a8c1fbe05206ebf59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I say keep it simple.<div><br></div><div>If the 75% thresh= old is hit, then support suddenly drops off below 50%, "meh" -- t= here will be a big ruckus, everybody will freak out, and miners will refuse= to build big blocks because they'll worry that they'll get orphane= d.</div><div><br></div><div>Adding more complexity for a case that ain'= t gonna happen (and isn't a disaster if it does) is a mistake, in my hu= mble opinion.</div><div><br></div><div><br></div></div><div class=3D"gmail_= extra"><br><div class=3D"gmail_quote">On Wed, Sep 23, 2015 at 2:33 PM, Tom = Harding via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev= @lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda= tion.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl= ass=3D"">On 9/13/2015 11:56 AM, Rusty Russell via bitcoin-dev wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> '''Success: Activation Delay'''<br> The consensus rules related to ''locked-in'' soft fork will= be enforced in<br> the second retarget period; ie. there is a one retarget period in<br> which the remaining 5% can upgrade.=C2=A0 At the that activation block and<= br> after, the bit B may be reused for a different soft fork.<br> <br> </blockquote> <br></span> Rather than a simple one-period delay, should there be a one-period "b= urn-in" to show sustained support of the threshold?=C2=A0 During this = period, support must continuously remain above the threshold.=C2=A0 Any lap= se resets to inactivated state.<br> <br> With a simple delay, you can have the embarrassing situation where support = falls off during the delay period and there is far below threshold support = just moments prior to enforcement, but enforcement happens anyway.<br> <br> BIP 101 has this problem too.<div class=3D"HOEnZb"><div class=3D"h5"><br> <br> <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><br clear=3D"all"><div><br></div>-- <br>= <div class=3D"gmail_signature">--<br>Gavin Andresen<br></div> </div> --089e013d0f5a8c1fbe05206ebf59--