On Wed, Mar 13, 2013 at 11:27 AM, Mark Friedenbach <m...@monetize.io> wrote: > This may be a semantic issue. I meant that it's not a hard-fork of the > bitcoin protocol, which I'm taking to mean the way in which we all > *expected* every version of the Satoshi client to behave: the rules which we
In our common language a hardfork is a rule difference that can cause irreconcilable failure in consensus; it's not some political change or some change in the user's understanding or something fuzzy like that. Please don't creep the definitions... but arguments over definitions are silly. If you really object to calling the causes consensus failure thing something else okay, then suggest a name, but whatever its called thats what we're talking about here. Your proposal of having a hardfork but only on the mining nodes has coordination problems. What happens if we don't know how to contact a majority of the hashpower to get them to turn off their special validation code? This is especially a concern because it's not unlikely that in a few months there may be solo miners with tens of TH/s... already we have a single party with nearly a majority, though at the moment they happen to be mining on the largest couple pools. Far better to have this special code just triggered on a deadline, which can be widely advertised as "you must upgrade to 0.7.4 or >0.8.1 before this time" and then all switch at once... and then we demonstrate the viability of a general mechanism that doesn't depend on poor miner decentralization. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
