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%, &quot;meh&quot; -- t=
here will be a big ruckus, everybody will freak out, and miners will refuse=
 to build big blocks because they&#39;ll worry that they&#39;ll get orphane=
d.</div><div><br></div><div>Adding more complexity for a case that ain&#39;=
t gonna happen (and isn&#39;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">&lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt;</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">
&#39;&#39;&#39;Success: Activation Delay&#39;&#39;&#39;<br>
The consensus rules related to &#39;&#39;locked-in&#39;&#39; 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 &quot;b=
urn-in&quot; 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--