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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 22EE7F9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Jan 2016 19:11:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148114.authsmtp.net (outmail148114.authsmtp.net
[62.13.148.114])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 525708A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Jan 2016 19:11:57 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u0TJBt0a062207;
Fri, 29 Jan 2016 19:11:55 GMT
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u0TJBrFR031709
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Fri, 29 Jan 2016 19:11:54 GMT
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 4735540140;
Fri, 29 Jan 2016 19:08:47 +0000 (UTC)
Date: Fri, 29 Jan 2016 14:11:52 -0500
From: Peter Todd <pete@petertodd.org>
To: Jannes Faber <jannes.faber@gmail.com>
Message-ID: <20160129191152.GA18253@savin.petertodd.org>
References: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3"
Content-Disposition: inline
In-Reply-To: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
X-Server-Quench: 28cbe30a-c6bc-11e5-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAsUElQaAgsB AmAbWl1eUVx7XGc7 bghPaBtcak9QXgdq
T0pMXVMcUQUMe25D cHweURh1dwwIf3l5 ZwhgViMJCUd6JFsu
RBwHCGwHMGJ9YGIW BV1YdwJRcQRDe0tA b1YxNiYHcQ5VPz4z
GA41ejw8IwAXAilO XklNJ1YVSkVDGCR0 ClhYRWxxXAULQD97
LxU8JhYSG1wSekw5 LVo/UE4ZNBlFYgAA
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] Best (block nr % 2016) for hard fork activation?
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: Fri, 29 Jan 2016 19:11:58 -0000
--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 29, 2016 at 03:31:05AM +0100, Jannes Faber via bitcoin-dev wrot=
e:
> On the other hand when a non-contentious hard fork is rolled out, one cou=
ld
> argue that it's actually best for everyone if the remaining 1% chain
> doesn't stand a chance of ever reaching 2016 blocks anymore (not even by a
> decent sized attacker trying to double spend on stragglers). Also causing
> all alarm bells to go off in the non-updated clients.
>=20
> Have people thought through all the different scenarios yet?
I wrote up some of those risks in my "Soft Forks Are Safer Than Hard
Forks" post the other week:
https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
I was writing mainly in terms of technical risks for deployment
non-controversial forks; for controversial forks there's many more
failure scenarios. In any case, on technical grounds alone it's obvious
that hard-forks without very high - 95% or so - activation thresholds
are quite dangerous.
In general, it should be remembered that high activation thresholds for
hard-forks can always be soft-forked down after the fact. For instance,
suppose we initially used 100% support over the past one month of blocks
as a hard-fork threshold, but can't get more than 96% support. A
soft-fork with the following rule can be implemented:
If 95% of the past blocks vote yes, voting against the hard-fork is
not allowed.
As soft-forks can be rolled out quite quickly, implementing this in the
event that a hard-fork isn't getting sufficient support won't add much
delay to the overall process; as it is a soft-fork, only miners need to
adopt it for it to take effect.
For this reason I'd suggest any hard fork use 99%+ activation
thresholds, measured over multi-week timespan. Hard-forks should not be
controversial for good social/political reasons anyway, so there's
little harm in most cases to at worst delaying the fork by two or three
months if stragglers won't upgrade (in very rare cases like security
issues there may be exceptions; blocksize is certainly not one of those
cases).
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000005822b77a904129795a3ff4167c57ed1044f5a93512c830f
--r5Pyd7+fXNt84Ff3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWq7l0XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwN2RmNTNkZGEyODBmMTQxNjhjYTJlYjYzMmIxYjg2YmJh
YmE1ZDkwZjdkMzhiNjAvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuzqgf/cuFXN2IT/l12nwrrzwO3KnuX
7MoeLwEhR8X0xIEd2lCrYyRKlFIFVV4F0fVzOl8fhLwBobZiGf0TylBYAHDf8DJN
G1Emn8nOuIqwjEFCpoEk+5niv4CUs5I7p7UVuKvjbRakMMEE358l4RJTaT6pJs7Q
3wXU3B81cUFPpOyVgLp/nksUgeJLLYnfBs6nF6mZZu655Zz15733H1ZPS3FYCMJb
0MputiDHLrGXu3vh67PYb08XtzvrufHI3KqGI9NVXlXCdG0aMkP+Hb4PU52VuN6H
sarBmUO70fRCw/d+WYq4+wr/85qTucSaAPhp+dPZ+x0QnPGLFitPI7hDTFmy5A==
=pNLE
-----END PGP SIGNATURE-----
--r5Pyd7+fXNt84Ff3--
|
