From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Pieter Wuille Message-ID: <20150620200751.GW13473@giles.gnomon.org.uk> References: <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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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