Quote from: lobcmt2 on January 18, 2019, 05:58:51 AM

I think that chain-splits are not the most important things, instead the separation or un-consensus of core team's members or communities are.
Splits should be focused on splits inside the core team or communities. It is likely that we all focus on wrong point, simply focus on the effects, not causes of those effects.

Forget about developers and vague terms like "community" for a moment. The problem here is confusion about what "consensus" means. It refers to network consensus, i.e. unanimous agreement among nodes about what the protocol rules are.

Let's not get bogged down with abstract notions about governance. It's more useful to begin from a point of accurate descriptions about how nodes actually interact with each other.

When it comes to a hard (backwards incompatible) fork, the idea of consensus is impossible to apply to a "community," particularly one as large as Bitcoin's. The idea that every single Bitcoin user is going to unanimously and consensually agree to a backward incompatible fork is completely insane. The only narrow case where every single users' incentives align to fork is where a protocol failure would render Bitcoin valueless. Otherwise, it's insulting to assume that every other user agrees to consensus-breaking changes. Outside of the narrow case mentioned -- or the case of a protocol with only a few users -- there is no such thing as "consensus to fork." That's just a rhetorical idea used to pressure other people into forking their software.

A hard fork or incompatible soft fork always means "chain split." A chain split means forking nodes have broken the consensus and opted out of the previous network. It already means splitting from developers or part of the community, by definition. It doesn't help to introduce notions of Core developers -- that's just an appeal to authority. If decentralization matters at all, we should be focused on what the network does, not what Core developers want.

Quote from: Lauda on January 18, 2019, 07:21:47 AM

If you really wanted to use the term upgrade, you might be able to use it only for soft forks. Unless a chain is completely centralized, a hard fork is always going to cause a chain split (read that again, always). That's why we call it a hard fork.

I like that, but at the same time, how do we deal with incompatible soft forks? Like a UASF that splits from the majority hash rate chain. In a technical sense, even a MASF with extremely high threshold for activation could still eventually cause a chain split.

I guess I don't really like "upgrade" being applied to protocol changes at all. It can be too loaded and political. The network is an organism -- it will do what it will. It doesn't bow to these sort of abstract terms.

I implicitly assume that node operators are rationally motivated to maintain consensus and upgrade the protocol. But I don't think it's my place to say what those upgrades should be or whether they're upgrades at all. That's for nodes to decide. Everything else is just talk.