Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5fqw-0004yU-Pj for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 19:51:58 +0000 X-ACL-Warn: Received: from hapkido.dreamhost.com ([66.33.216.122]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Z5fqv-0008U6-KT for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 19:51:58 +0000 Received: from homiemail-a8.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by hapkido.dreamhost.com (Postfix) with ESMTP id A87FC9BA66 for ; Thu, 18 Jun 2015 12:31:58 -0700 (PDT) Received: from homiemail-a8.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a8.g.dreamhost.com (Postfix) with ESMTP id 3DB0BD22082 for ; Thu, 18 Jun 2015 12:31:53 -0700 (PDT) Received: from [192.168.0.6] (cpc12-cmbg17-2-0-cust830.5-4.cable.virginm.net [86.30.131.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jrn@jrn.me.uk) by homiemail-a8.g.dreamhost.com (Postfix) with ESMTPSA id D4A57D22072 for ; Thu, 18 Jun 2015 12:31:52 -0700 (PDT) Message-ID: <55831CAB.2080303@jrn.me.uk> Date: Thu, 18 Jun 2015 20:31:55 +0100 From: Ross Nicoll 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> <20150618111407.GA6690@amethyst.visucore.com> <0ede5c200ce70e4d92541dd91749b4ea@riseup.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [66.33.216.122 listed in list.dnswl.org] X-Headers-End: 1Z5fqv-0008U6-KT Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers 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: Thu, 18 Jun 2015 19:51:58 -0000 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