Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me
	designates 192.241.179.72 as permitted sender)
	client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me;
	helo=mail.bluematt.me; 
Message-ID: <554AA012.8090008@bluematt.me>
Date: Wed, 06 May 2015 23:13:22 +0000
From: Matt Corallo <bitcoin-list@bluematt.me>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Matt Whitlock <bip@mattwhitlock.name>, 
	bitcoin-development@lists.sourceforge.net
References: <554A91BE.6060105@bluematt.me> <1569618.2AHoSKjX9r@crushinator>
In-Reply-To: <1569618.2AHoSKjX9r@crushinator>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

For now, lets leave the discussion to JUST the block size increase. If
it helps - everyone should assume that their pet feature is included in
a hard fork or, if you prefer, that no other features are included in a
hard fork.

On 05/06/15 23:11, Matt Whitlock wrote:
> I'm not so much opposed to a block size increase as I am opposed to a hard fork. My problem with a hard fork is that everyone and their brother wants to seize the opportunity of a hard fork to insert their own pet feature, and such a mad rush of lightly considered, obscure feature additions would be extremely risky for Bitcoin. If it could be guaranteed that raising the block size limit would be the only incompatible change introduced in the hard fork, then I would support it, but I strongly fear that the hard fork itself will become an excuse to change other aspects of the system in ways that will have unintended and possibly disastrous consequences.
>