MIME-Version: 1.0
In-Reply-To: <CAE-z3OVKWfKOxQaAkB1_09f+v1FgkPCZCR-UxfnA008NDjGb5g@mail.gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
	<CAE-z3OVKWfKOxQaAkB1_09f+v1FgkPCZCR-UxfnA008NDjGb5g@mail.gmail.com>
Date: Mon, 22 Jun 2015 14:46:03 -0400
Message-ID: <CABsx9T1FOkc0C2EcD4s4XB0D=tpaDs27smeL__P=nRLByr_dfg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=001a11345984898d6f05191faffd
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list

--001a11345984898d6f05191faffd
Content-Type: text/plain; charset=UTF-8

On Mon, Jun 22, 2015 at 2:33 PM, Tier Nolan <tier.nolan@gmail.com> wrote:

> The BIP-100 proposal uses a window of 12000 blocks (83 days) rather than
> the standard 1000.  Given that the threshold is lower than is normal for
> hard-forks, noise on the measurement could cause an activation even if less
> than 75% of miners agree.  It also means that the vote has to be sustained
> for longer and inherently gives a longer notice period.
>

9,000 of last 12,000 blocks is OK with me (I don't think scanning through
the last 12,000 block headers every new block will cause performance
problems, but I'd want to benchmark it to be absolutely sure).


> Two weeks seems low for an upgrade warning.  I guess there would be an
> alert on the network.
>
Do old nodes detect an upgrade by version numbers?  If that was headers
> only, then they could detect that large blocks have activated.
>

Bitcoin Core will alert when automatically when 51% of blocks have a
version it doesn't understand.

It will also alert automatically if it detects a chain with more work that
it doesn't consider valid for some reason. And 0.11 contains code that
alerts if you're on a chain that is being mined really slowly.

Have you considered a "fail" condition?  For example, if 750 of the last
> 1000 blocks set bits 4 and 14, then it counts as a rejection by 75% of the
> miners.  Alternatively, if the rule doesn't activate by 11th Jan 2017, then
> it is disabled.
>

I like the fail-if-not-activated-by idea. Not so crazy about the vote idea
(what if miners set bits 3 AND 4 ?).

-- 
--
Gavin Andresen

--001a11345984898d6f05191faffd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jun 22, 2015 at 2:33 PM, Tier Nolan <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:tier.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>T=
he BIP-100 proposal uses a window of 12000 blocks (83 days) rather than the=
 standard 1000.=C2=A0 Given that the threshold is lower than is normal for =
hard-forks, noise on the measurement could cause an activation even if less=
 than 75% of miners agree.=C2=A0 It also means that the vote has to be sust=
ained for longer and inherently gives a longer notice period.<br></div></di=
v></div></blockquote><div><br></div><div>9,000 of last 12,000 blocks is OK =
with me (I don&#39;t think scanning through the last 12,000 block headers e=
very new block will cause performance problems, but I&#39;d want to benchma=
rk it to be absolutely sure).</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div><div>Two weeks seems low for an upgrade warni=
ng.=C2=A0 I guess there would be an alert on the network.<br></div></div></=
div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>=
Do old nodes detect an upgrade by version numbers?=C2=A0 If that was header=
s only, then they could detect that large blocks have activated.<br></div><=
/div></div></blockquote><div><br></div><div>Bitcoin Core will alert when au=
tomatically when 51% of blocks have a version it doesn&#39;t understand.</d=
iv><div><br></div><div>It will also alert automatically if it detects a cha=
in with more work that it doesn&#39;t consider valid for some reason. And 0=
.11 contains code that alerts if you&#39;re on a chain that is being mined =
really slowly.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div></div></div>Have you considered a &quot;fail&quot; condi=
tion?=C2=A0 For example, if 750 of the last 1000 blocks set bits 4 and 14, =
then it counts as a rejection by 75% of the miners.=C2=A0 Alternatively, if=
 the rule doesn&#39;t activate by 11th Jan 2017, then it is disabled.</div>
</blockquote></div><br><div>I like the fail-if-not-activated-by idea. Not s=
o crazy about the vote idea (what if miners set bits 3 AND 4 ?).</div><div>=
<br></div>-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></d=
iv>
</div></div>

--001a11345984898d6f05191faffd--