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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <roy@gnomon.org.uk>) id 1Z6P3j-0006Zb-5U
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 20:08:11 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gnomon.org.uk
designates 93.93.131.22 as permitted sender)
client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
helo=darla.gnomon.org.uk;
Received: from darla.gnomon.org.uk ([93.93.131.22])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Z6P3h-00069s-IZ
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 20:08:11 +0000
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id t5KK7raH039898
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Sat, 20 Jun 2015 21:07:58 +0100 (BST)
(envelope-from roy@darla.gnomon.org.uk)
Received: (from roy@localhost)
by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id t5KK7ran039897;
Sat, 20 Jun 2015 21:07:53 +0100 (BST) (envelope-from roy)
Date: Sat, 20 Jun 2015 21:07:53 +0100
From: Roy Badami <roy@gnomon.org.uk>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20150620200751.GW13473@giles.gnomon.org.uk>
References: <CAPg+sBijQ0Q9U00hUaotYujqW8M+v1ED+PV+ap2g7b0Z4=RNSA@mail.gmail.com>
<CAPg+sBhb6TyS=Bz4chLixw4Qc0Q1w6VdW-YTHZ-O_fyfvCJ+6Q@mail.gmail.com>
<20150620184250.GV13473@giles.gnomon.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150620184250.GV13473@giles.gnomon.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: -2.1 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1Z6P3h-00069s-IZ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Hard fork via miner vote
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 20 Jun 2015 20:08:11 -0000
> I just wish that half as much energy had gone into discussing
> whether we want a 100% supermajority or a 99% supermajority or an
> 80% supermajority, as has gone into discussing whether we want 1MB
> blocks or 8MB blocks or 20MB blocks.
And I understand that Gavin is now proposing that a 75% supermajority
should be enough. This constantly reducing threshold worries me
greatly.
There is a risk that we get a situation where a stable amount of
hashing power somewhat over 75% (say 80%) accepts the fork - and
therefore triggers it - but both a significant minority (say 20%) of
hashrate rejects it *and* the economic majority rejects it.
I'm not saying this is a likely outcome - indeed I hope it's not - but
it is a _possible_ outcome. Ok, the chain that the economic marjority
is using will have a bit of a temporary crisis due to 50 minute block
times, but it will recover in a few weeks as difficulty adjusts. And,
in the worst case, you end up with two competing semi-stable
ecosystems both claiming to be 'the real Bitcoin'.
My fear is that in that situation it could take an extended period -
perhaps many months - for one fork to clearly win and the other fork
to lose support (or at least lose sufficient support to be relegated
to altcoin status). I think such an extended period of uncertainty
would be the ultimate worst case scenario for Bitcoin. It _probably_
wouldn't be fatal to Bitcoin, but it would certainly be far worse for
Bitcoin than getting the blocksize wrong even by an order of magnitude
(in either direction). Therefore if we can design the hardfork
mechanism to make such an outcome impossible, I believe we really need
to.
roy
|
