Quote from: we-btc on Today at 05:32:45 PM

My understanding (please correct me if I am wrong) is that node operators have the ability to choose the version or Core they run. This allows nodes to decide which changes they wanted to support.

not anymore
core mad things more "backward compatible" so that it doesnt require user nodes to be network reedy before a network change takes effect. thus users nodes do not even have any consensus effect on if a feature activates or not

its now just down to service nodes(economic nodes) of things like exchanges/popular institutional services for mass customers which can mandate mining pool nodes to comply or else have blocks rejected. as seen happening in the past..

Quote from: we-btc on Today at 05:32:45 PM

If nodes took on this responsibility than developers wouldn't be a centralizing factor and there would be less motivation to manipulate them with money. With a diversified group running the nodes than code manipulation would be less of an issue.

when the choice of protocol direction is core vs.. core vs.. core.. is there really a choice
REKT campaigns have been done if any other brand attempted to propose upgrades, they were relegated to being treated as altcoin options should their proposals activate against the core roadmap

Quote from: we-btc on Today at 05:32:45 PM

Could the Core team make it easier to change the version of Core that a node operator is running? This would help solve the problem.

they already made it easier with "backward compatibility" where user nodes dont even need to upgrade when new core features upgrade.. the users nodes just blind passes the new style data as valid without actually checking.