Can a Mining Pool Force Changes Without Agreement from Bitcoin Core Developers? I'm trying to understand a @petertoddbtc tweet about Chinese miners making a controversial stance.
 According to the accompanying article https://www.cryptocoinsnews.com/bitcoin-market-needs-big-blocks-says-founder-btc-top-mining-pool/, the Chinese miners advocate Bitcoin Unlimited.
 Bitcoin Unlimited allows large blocks (>1MB?). In contrast, Bitcoin Core Developers
 are considering limiting to smaller blocks (300KB).

There are quotes from Zhuoer who controls 8% of total hashrate and is rallying the Chinese miners:


  Who goes against the market will be destroyed, unless he can show more money.


In regards to Luke-Jr's (Core developer) threat of hardfork, there is the reaction:


  We have prepared $100M USD to kill the small fork of CoreCoin.


Isn't change supposed to be with the agreement of all developers, miners, and consumers?
 Can the mining pool group force this change on the Core developers?
 Why is Bitcoin Unlimited so different from Core, and what makes it incompatible to Core
 in that now there is a rift between miners and the Core developers?
In contrast, Bitcoin Core Developers are considering limiting to smaller blocks (300KB).


First of all, for these kinds of changes, Bitcoin Core only merges things with very wide consensus. There was a proposal for 300kB blocks by one individual developer, which I think everyone considers to be very controversial.

Furthermore, these kinds of changes are not proposals for changing Bitcoin Core's behaviour and forking off. They're proposals for changing Bitcoin, and that's not something that is to be decided by the authors of one piece of software.

Then, on to answering your question:

The (collection of) economically relevant full nodes on the network determine the network's rules. I say economically relevant, because someone running 1000 nodes in a cluster, and have them do nothing but connect to the network and relay transactions and blocks is not going to affect anyone. I also say collection, because I'm ignoring the issue of how those nodes' operators come to an agreement.

Miners' job is to build blocks that satisfy those rules. They can choose to not do so, but their blocks will be rejected by the network if they do, and they'll lose their income from those.

However, miners can always choose to enforce extra rules on top of those demanded by the network. That's the first step towards a soft fork, but it's not enough. It's just a collusion of miners agreeing among each other to only build on top of other blocks that satisfy some extra criterion. They could even do this without telling anyone.

That is not yet a softfork, because they could just as easily agree to stop doing something like this. To make it a successful softfork, economically relevant full nodes in the network need to start enforcing the same rules at the same time. That is what makes the change lock in. Because if full nodes are in on it, miners can no longer back out - doing so would either invalidate their blocks, or cause an irreconcilable fork in the chain. BIP9 is a mechanism for allowing miners to coordinate the activation of a new feature, and having full nodes activate it simultaneously.

So in short: softforks are subject to a majority of the hashrate plus significant adoption of enforcing code on economically relevant nodes. Developers of particular software do not directly control either, but obviously do have an influence by providing the means to deploy such software.

Disclaimer: I'm a Bitcoin Core developer.