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. > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
