Message-ID: <55831CAB.2080303@jrn.me.uk>
Date: Thu, 18 Jun 2015 20:31:55 +0100
From: Ross Nicoll <jrn@jrn.me.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <55828737.6000007@riseup.net>	<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>	<20150618111407.GA6690@amethyst.visucore.com>	<CAPg+sBj_go==m6-++sA53imYdz4OLH4bkyiuAyEM8YR8CaTd=w@mail.gmail.com>	<CAJHLa0OKXaUD6MnN4N6RGbNwrXx43jBm9MiELQK6BRw1OL3HNA@mail.gmail.com>	<0ede5c200ce70e4d92541dd91749b4ea@riseup.net>	<CAJHLa0NiDamkrbW2TMoTLqMPhzw0LBboNp1+_atBGDYMa135uw@mail.gmail.com>	<e6da277c39b0354cdf24361e20a1fce2@riseup.net>	<CAPWm=eX5Oc4QXkp3H5thPBPzJ-t7JGzF5pVaP+eSd0=h52ku=A@mail.gmail.com>	<CABsx9T1ENeoZ968PDGUgBPdZLmkwRCDtBvZ2BwT0HaFdWxSL3g@mail.gmail.com>
	<CABm2gDoa7KxsgvREo3yiNjfd6AeayqAqkjMe2rvX8yyxR_ddcA@mail.gmail.com>
In-Reply-To: <CABm2gDoa7KxsgvREo3yiNjfd6AeayqAqkjMe2rvX8yyxR_ddcA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
 to Remove Commit Access from Other Developers
Precedence: list

I've got a few thoughts on this, but they don't really attach well to a 
single message, so starting a fresh message in the same thread. I'm 
going to try being brief.

There's a lot of talk about not forking. Sorry, but they're going to 
happen, planned and unplanned. Even if no intentional forks occur from 
here on, I hope it's obvious that there will be further accidental forks 
(at least unless and until someone prepares a formal proof of a Bitcoin 
wallet). We need to be more comfortable with that, and plan ahead. 
Education is key here, a lot of people don't understand what a fork is, 
how it will affect them, how to recognise a fork or how to recover. I'll 
dig out what materials I've written already and try making them more 
widely available, as a start.

On whether code forks are a solution to disagreements - I'm not quite 
sure what people expect will happen where a group believes there is an 
existential threat to Bitcoin and they cannot get Bitcoin Core updated. 
I may disagree with Mike & Gavin on timescale, but I do believe there's 
a likelihood inaction will kill Bitcoin, and in that context I see the 
rational choice as taking the perceived smaller risk of a fork killing 
Bitcoin. BIP100 appears to be making progress, however, right now I 
think the best option is pursuing it towards something that can be 
agreed on by all. I would also happily go with an 8MB block size even if 
just to buy us (IMHO a lot) more time.

Lastly, there seems to be a number of people who believe inaction 
through apathy is fine. I respect those who form considered opinions and 
tell me why they believe 1MB is fine, but I do ask that people either 
put the effort in to help make decisions, or delegate to someone else. 
Decentralised does not mean there's no decision making, it means we're 
all decision makers, and frankly I think there's effectively negligence 
in that capacity right now. I'd also point out this ongoing discussion 
is a huge time sink to a number of people who could be making much more 
useful contributions, and that again going in circles endlessly 
discussing in the name of decentralisation isn't positive.

I have failed at being brief, apologies.

Ross