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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
