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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AE090BAC
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2017 21:20:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 4BE4E193
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Feb 2017 21:20:36 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 8843038A230C;
Tue, 28 Feb 2017 21:20:30 +0000 (UTC)
X-Hashcash: 1:25:170228:shaolinfry@protonmail.ch::dYiwfcM4bk/bfBCO:xiX=
X-Hashcash: 1:25:170228:bitcoin-dev@lists.linuxfoundation.org::PlpMmTwh6i2j2X0a:eBps
From: Luke Dashjr <luke@dashjr.org>
To: shaolinfry <shaolinfry@protonmail.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 28 Feb 2017 21:20:29 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.45-gentoo; KDE/4.14.24; x86_64; ; )
References: <jo5-7HCZX7tgdMpIQgK85HCPP14FWxvOIbjV_oerIfc-HOP1GbK3SxFX82Ls23yU1L7y95QsFFggddMNdo5Sxy7YhTJhRFN1f8d6PaA8b7s=@protonmail.ch>
In-Reply-To: <jo5-7HCZX7tgdMpIQgK85HCPP14FWxvOIbjV_oerIfc-HOP1GbK3SxFX82Ls23yU1L7y95QsFFggddMNdo5Sxy7YhTJhRFN1f8d6PaA8b7s=@protonmail.ch>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201702282120.29614.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Tue, 28 Feb 2017 21:20:36 -0000
Without at least a majority hashrate validating blocks, it is possible just a
single invalid block could split the chain such that the majority continue
building a most-work on that invalid block.
This failure to validate a softfork is similar in some respects to a hardfork,
but with one critical difference: the default behaviour of old nodes will be
to follow the chain with the most-work that was valid under the pre-softfork
rules. This actually *inverts* the benefit of the softfork over a hardfork,
and makes a softfork deployed in such a manner de facto behave as if it had
been a hardfork, IF someone ever mines a single malicious block.
For this reason, I think a minority-hashrate softfork requires a much higher
degree of social support than merely the widespread agreement typical of
softforks. It might perhaps require less than the full ~100% consensus
hardforks require, but it likely comes somewhat close.
Once it gets over 50% hashrate enforcement, however, the situation improves a
lot more: a malicious block may split obsolete miners off the valid chain, but
it will eventually resolve on its own given enough time. Due to natural
fluctuations in block finding, however, automatic measurement may need to look
for >75%.
So I would suggest that instead of a simple flag day activation, this proposal
would be improved by changing the flag day to merely reduce the hashrate
requirement from 95% to 75%.
(In addition to the above concerns, if >50% of miners are hostile to the
network, we likely have other problems.)
Luke
|
