What are you trying to do? Break the ice with a hard fork so that later it becomes easier to do so, with people more complacent towards it? There are many solutions to the scaling problem that do not require a hard fork and are quite simple to implement actually, and don't come with the complications involved with a hard fork. I'm not a reputable developer on this list, so my opinion probably doesn't matter much, but I watched and analyzed this situation closely and I don't like this idea.

On Fri, Jul 17, 2015 at 3:55 PM, Jeff Garzik via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Opening a mailing list thread on this BIP:

BIP PR: https://github.com/bitcoin/bips/pull/173
Code PR: https://github.com/bitcoin/bitcoin/pull/6451

The general intent of this BIP is as a minimum viable alternative plan to my preferred proposal (BIP 100).

If agreement is not reached on a more comprehensive solution, then this solution is at least available and a known quantity. A good backup plan.

Benefits: conservative increase. proves network can upgrade. permits some added growth, while the community & market gathers data on how an increased block size impacts privacy, security, centralization, transaction throughput and other metrics. 2MB seems to be a Least Common Denominator on an increase.

Costs: requires a hard fork. requires another hard fork down the road.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647