summaryrefslogtreecommitdiff
path: root/74/a96caf8304e8f7cc08640e63b66c592af4ac25
blob: 32c2b275ab0ab32cf20df22e6fdf948aa1110056 (plain)
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
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 28FB3273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 18:33:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com
	[209.85.192.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BA733133
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 18:33:45 +0000 (UTC)
Received: by qgal13 with SMTP id l13so55669836qga.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 22 Jun 2015 11:33:45 -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:cc
	:content-type; bh=+V1Mq6RiLIFtdyYimxGzVWN+d+lL8xPEJUDtslZRt0Q=;
	b=PilvGA/DjpcO7e/1GVvCg24k0iyQ5euzzf88LpQ67SnJ9wzAAkDBkyKG60uUtr2cfB
	MkTLrIqJVoKMuUwRzpSkSZtpG7UyK4YVC7jSh4Jax9PWpVeBVqDPmpHk1omGydwl1HHe
	vb+c8twRtwqcJrNddkK6lQU4DaOtqI+HM6eQ7mt0tLM8ZNuHNmg4cU8302/kJYEWXDEE
	wg3jv5K7WA1obBhD/hb4jVxxyqdt+As+BCcuWN9TS1g4qkalwVy+bPWHTnrJcDQrbbnq
	1MsuSvOaCgiCJXDx6zdAbQKHIVCHq9xVyRNuyF9TxlaQ4XkV+voEBHlqvLANJE2IembH
	KJJg==
MIME-Version: 1.0
X-Received: by 10.140.109.34 with SMTP id k31mr39725718qgf.94.1434998025067;
	Mon, 22 Jun 2015 11:33:45 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Mon, 22 Jun 2015 11:33:45 -0700 (PDT)
In-Reply-To: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
Date: Mon, 22 Jun 2015 19:33:45 +0100
Message-ID: <CAE-z3OVKWfKOxQaAkB1_09f+v1FgkPCZCR-UxfnA008NDjGb5g@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113a7d0a89a42805191f8305
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
	RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.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:33:46 -0000

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

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.

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.

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.

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

<div dir=3D"ltr"><div><div>The BIP-100 proposal uses a window of 12000 bloc=
ks (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 caus=
e an activation even if less than 75% of miners agree.=C2=A0 It also means =
that the vote has to be sustained for longer and inherently gives a longer =
notice period.<br><br></div><div>Two weeks seems low for an upgrade warning=
.=C2=A0 I guess there would be an alert on the network.<br><br>Do old nodes=
 detect an upgrade by version numbers?=C2=A0 If that was headers only, then=
 they could detect that large blocks have activated.<br></div><br></div>Hav=
e you considered a &quot;fail&quot; condition?=C2=A0 For example, if 750 of=
 the last 1000 blocks set bits 4 and 14, then it counts as a rejection by 7=
5% of the miners.=C2=A0 Alternatively, if the rule doesn&#39;t activate by =
11th Jan 2017, then it is disabled.<br></div>

--001a113a7d0a89a42805191f8305--