Borrowing here from some of my recent reddit comments:
"Hard fork" and "Soft fork" definitions
I assume that when most people talk about a "hard fork" they're referring to the situation where a
majority of the hash power loosens the rule set they're using to determine "validity." (And arguably the fork only really occurs when the first block that would have been invalid under the old rules is mined and successfully avoids orphaning.) If only a
minority of the hash power begins to apply a strictly looser rule set, nothing happens -- except that those in the minority may periodically have their blocks orphaned and/or temporarily follow doomed-to-be-orphaned chains.
Similarly I think when most people talk about a "soft fork," they're referring to the situation where a majority of the hash power begins to enforce a stricter rule set. This "prevents a chain split" by essentially 51% attacking those who don't upgrade. Of course, making a protocol change as a soft fork can't
really guarantee that the chain won't split. Because if the change is sufficiently controversial, the disgruntled minority may attempt to organize a counter fork to avoid being swept along with the rule change. A soft fork just increases the coordination cost of resisting an unpopular or controversial change. (And here again, I'll note that a "51% attack" is just another name for a malicious soft fork.)
It's also worth noting that if only a
minority of the hash power "soft forks" (begins to enforce a stricter rule set),
that will cause a chain split. So the idea that "hard forks risk chain splits" seems misguided -- and indeed essentially backwards.
Chain splits are always ultimately caused by the willingness of some individuals to either begin enforcing, or continue enforcing, a "validity" rule -- even when doing so means that they will be following a chain other than the "longest" / most-proof-of-work chain.
As an aside, this is why it's at least somewhat imprecise to talk about a "minority hard fork" (although I've been guilty of this myself in the past). So for example, if we wanted to create a "big block" fork now without a hash power majority, we would need to do so via a combination hard and soft fork (and it would be the
"soft fork" elements of that fork that would actually be responsible for separating us from the other chain).
If and when a "fork" has occurred is fundamentally indeterminate
This is because the "current consensus rules" are fundamentally indeterminate. You only really know for sure what software
you're running. It's technically possible (although we imagine, extremely unlikely) that everyone else on the network is actually running a modified Core client (or BU or Classic) that would accept > 1-MB blocks today. Related to this point is that the idea that the difference between
"artificial" and "natural" orphaning risk is indeterminate. When one of your blocks is orphaned by the rest of the network, you can never be
entirely sure why that occurred. Now obviously
right now this probably seems like a really theoretical or academic point. After all, a large majority of the hash power is advertising that they're running some version of Core and so we're all probably 99.99% confident that they are in fact running an unmodified version that would reject any block larger than >1 MB. But that doesn't mean that this fundamental indeterminacy won't be more palpable in the future.
Three levels of "validity" rule enforcement
It seems to me that there are arguably three levels of commitment to validity rule enforcement:
Provisional enforcement of a rule in an effort to stay with the current hash power majority
You may choose to enforce a validity rule in an effort to "stay with the herd," i.e., because you believe that the hash power majority is currently enforcing the rule in question. This is what BU enables with respect to block size. When you run BU with an EB setting of X and a reasonable, finite AD setting, you're not really treating "excessive" blocks as "invalid." Your enforcement of that limit is expressly provisional. You're basically saying: "I'll defer acceptance of blocks larger than X because I predict that's what the network as a whole will do at this time. But I could be wrong, and I'll ultimately follow whichever chain proves to be the longest. I'm certainly not willing to permanently fork myself off onto a minority chain over block size. That would be crazy."
Forcing a market referendum when the hash power majority is dangerously wrong
In rare cases, you may also choose to enforce a validity rule even when you're confident that doing so puts you in the current hash power minority. This could be a scenario where you believe that the herd's mining majority has "gone over a cliff." You still want to "stay with the herd" (remain on the chain that will ultimately be economically dominant) but you need to enable the larger herd (i.e., the market / all investors as a class) to help you rein in the errant miners. You can do this by forcing a chain split and allowing coins on the two chains to be traded against one another. If you're correct and the market values your chain more than the higher hash power chain, it will eventually
become the longest chain (because hash power ultimately follows price).
Servicing a separate niche in the case where a persistent split makes sense
Finally it's possible that you may be willing to enforce a validity rule even when you know that doing so will put you on the minority chain
and that the minority chain is likely to
remain the minority chain. This may be rational if you believe that the minority chain will serve a viable niche that cannot be satisfied by the majority chain.
