I have a hypothetical question. Let us pretend that a hard fork indeed happened. For this example let us use BitcoinXT as the new version to be used in the fork. If the hard fork ended up like the one that happened to Ethereum, who is to blame and what should be done? Now we have two Bitcoin chains and both have die hard supporters unwilling to let go for each.
If there is anyone to blame it is the proponents of the hard fork, because they initiated a network split. There is nothing to be done about it. Miners will mine any chain which it is rational to mine on; there's no way to stop miners from securing either chain. And whether it's rational for miners depends on users; there is no way to force users to use one client or the other.
So if users remain on the original chain, the network will likely split and we will permanently have multiple incompatible networks/blockchains. It doesn't matter which chain has more work (POW) because the two networks cannot communicate with one another.
There would not have been a need for a split if people weren't so stubborn as to religiously hold on to an obsolete 1MB blocksize limit.
That you refer to us as "religious" shows how biased you are. I could say the very same of you---so obsessed with the idea of hard forking when there are far less risky and more ethical options.
If a fork is miner-activated, this is economic coercion to thwart user consent. Consensus (and breaking consensus, i.e. hard forking) concern ethical issues like this:
When you opt in to the network, you and all participants enforce the consensus rules. This entails rejecting invalid blocks not abandoning the consensus rules anytime 51% (or 75%) of miners tell you to. Such attempts to break consensus are an attack on the very idea of participating in a consensus network. If a majority of miners can coerce the network into abandoning the rules every user has agreed to, only by virtue of its hash power, then Nick Szabo is correct to call this technologically equivalent to a 51% attack.
This is why the idea of economic coercion is so relevant here. Fundamentally threatening the value of a holders money is the rational basis for forcing a network migration. No one wants to be left on the minority chain means specifically that miners have ultimately decided, not users. This is why I want to stress to readers that there is no such thing as majority/minority chains in a hard fork. There are merely multiple networks.
http://cointimes.tech/2016/08/hard-forks-and-consensus-networks-meta-questions-and-limitations/#commentsI don't think it is "mindless fear" to point to Ethereum's failed hard fork and point out that it permanently split the network. This caused significant losses for custodians---Coinbase lost ETC and still hasn't repaid their customers. BTC-E was replay attacked and lost all of their customers' ETC; they won't be repaying it. The results would have been disastrous if Kraken and Poloniex didn't have the foresight to ignore the Ethereum Foundation's advice to ignore ETC and not repay their customers their money. Replay attacks were commonplace, and many users lost money in trying to spend on only one chain or the other. Bitcoin is actually in a far worse position for this than Ethereum---no one uses Ethereum for virtually anything. It's a bloatchain full of "hello, world." It's hardly used for merchant payments, cross-border payments, and there is hardly an economy to speak of. The losses incurred by users and custodians in a failed Bitcoin hard fork could be far worse than in Ethereum. Further, Ethereum doesn't even have a finite supply limit (and is widely viewed not as a store of value). The effects of splitting the Bitcoin network and increasing the supply of "bitcoins" across multiple blockchains could be far worse for Bitcoin's value proposition than a network split in Ethereum.
The sigops issue is a DOS attack vector. For example, a malicious miner can essentially force the network to get collectively stuck validating a single block for many minutes. Here's the worst at 1MB:
https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_transaction_ever_mined_999657_kb_consumes/csvahznForcing increased throughput on nodes without backward compatibility is a node centralization issue:
https://bitcointalk.org/index.php?topic=1344522.msg13915026#msg13915026Forcing increased throughput on miners without effective latency mitigation is a miner centralization issue:
https://www.reddit.com/r/bitcoin_devlist/comments/3bsvm9/mining_centralization_pressure_from_nonuniform/More generally, I support demand for block space outpacing capacity, to prevent the worst-case scenarios concerning ineffective fee markets:
https://botbot.me/freenode/bitcoin-wizards/2015-08-25/?msg=48126773&page=3Storage costs are a concern as well in the context of unlimited block size, but a lesser one. But the general point is that increasing resource usage without scaling mechanisms makes nodes and miners drop off the network. So if we are dead set on increasing capacity, we should do it in a backward compatible way. This has the added benefit of not splitting the network.....