From: Matt Whitlock <bip@mattwhitlock.name>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 06 May 2015 19:11:04 -0400
Message-ID: <1569618.2AHoSKjX9r@crushinator>
User-Agent: KMail/4.14.7 (Linux/3.18.11-gentoo; KDE/4.14.7; x86_64; ; )
In-Reply-To: <554A91BE.6060105@bluematt.me>
References: <554A91BE.6060105@bluematt.me>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

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.