in the case of a hard fork, i'll be plugging away on my Core node. if you want 2 chains, you got it. and yes, i'll be doing my best to double spend on the "Classic" chain to make the fork irreparable. just doing my part.
relax. the core team are not telling people that orphans will take care of the chances of alternate chains. i do love their hypocracy of doomsday scenario's without merit just to try winning favour out of fear.
by hypocracy i mean by them(blockstR3am) not adding 2mb to sit as a buffer. they themselves will be causing the issues if miners decided to move forward but core doesnt allow users to have the setting to cope with the change
What do you mean by the bolded? I can't really figure out what you're saying. Are you suggesting that in a 75% hard fork scenario, that multiple surviving chains are impossible?
How is that hypocrisy? Why would we do a 2mb hard fork when segwit give us nearly that or more? If miners move forward with 2mb without Core -- and I think that is highly unlikely (I think you and others greatly overestimate the stupidity of large-scale miners) -- that would be their fault. It would be their fault for running a barely-tested version of bitcoin and expecting the rest of the ecosystem to do the same on very little notice, on the word of a ragtag minority of devs who have done nothing to suggest they are capable of maintaining bitcoin.
And you might just find that, in such a situation, a good deal of that hashpower makes its way back to the original (1mb limit) blockchain shortly before or after the hard fork is triggered.
a 70% trigger, just changes a 1000000 into 2000000... which sits as a buffer, miners can still make small blocks nothing will force miners to make blocks over 1mb until they personally choose to(which could be months or years, whenever they choose to). its not a nuclear trigger.. and just a buffer increase when the consensus shows that there is a possibility that capacity may grow soon. even after the 28 days are up, if miners think the risk of orphan is still high due to many other things. they wont push the envelope. and that 2000000 will just sit there as nothing more then a buffer
What are you talking about? You can't talk about "miners" as a single entity. A node is either running one version of the software or the other, assuming they are incompatible (in this case, the are). That means that after the hypothetical 28 days, if 70% are running node software that accepts > 1MB blocks, once any single miner or pool publishes a block that is valid based on 2mb parameters but not 1mb, we have passed the point of no return. "They won't push the envelope?" How could you pretend to predict the actions of every single CPU contributing hashpower to the network?
You've already predicted that 0% out of 100% of hashing power will publish a block breaking the old consensus rules -- that the new limit "is nothing more then a buffer," even if 70% ran the node software at some point in order to activate the new rules. On its face, that is extremely unlikely given that it only takes one actor with a modicum of hashing power to cause the node software of a majority of miners to enforce the new consensus rules.
So once Gavin's 28 days are up and any one miner or pool publishes a >1MB block, hashpower ceases to be the question at all. The question becomes which chain node operators consider valid.
Do you then go on to predict that 100% of nodes will be running one version of the software (1mb limit) or the other (2mb limit)? Because if not, we will inevitably have an irreparable chain fork.
If you want to know whether a hard fork activating with 70% of hashing power can break bitcoin into multiple blockchains (presumably forever, as too much value will have changed hands to conceivably "roll back")... the answer is unequivocally YES.