1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
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 677E883D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 18:46:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com
[209.85.217.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B0FCA156
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 18:46:04 +0000 (UTC)
Received: by lbbwc1 with SMTP id wc1so114625643lbb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 22 Jun 2015 11:46:03 -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=GV0zhIF7toURolrXDV9n2RI5494u1rsVeRjelGZStr0=;
b=dW2lgTxS4sntqRfdYojq6fbhjhDdO5v/J7+4tyCPDGp11BCu2am6zeBu7+kTjIeYQy
8xX3wsbKKPROKm64+6ALuxe7DTH/jYEOzVnwnM/194ytaY2h/0vxOY9DnnqeCKbSIR3U
70tSOOyOOn1FvFk68N0HMOVkPkOK/ri+ijDO8b5bNkSRBXJn5TOokdsewcuxD+5fgWd7
/oO2uCQ79y0oMcLY+r+RjNSPluGT8T9O1qjdTcXHtUMOaglOrkB9jv6ndKkm9cNFsLPy
hbT8DkCiDP0gP0WNOkzZ7FLaGNuw9usq9BHf0IYz+QwdCtr7Eh7aSHyHRbV+JUrB0PCk
Evtg==
MIME-Version: 1.0
X-Received: by 10.152.203.233 with SMTP id kt9mr30189444lac.99.1434998763258;
Mon, 22 Jun 2015 11:46:03 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Mon, 22 Jun 2015 11:46:03 -0700 (PDT)
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
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
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: Mon, 22 Jun 2015 18:46:05 -0000
--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"><<a href=3D"ma=
ilto:tier.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>></=
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't think scanning through the last 12,000 block headers e=
very new block will cause performance problems, but I'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'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'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.</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 "fail" 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'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--
|
