Unlike Coinbase, their employees and founders (currently) have and are exercising the power to veto any hardfork, even a bump to 2MB.
You are very confused. Core cannot force the miners , nodes, processors, and users what code to use. The veto is completely within our power. All I have to do I download a copy of Bitcoin XT or unlimited and I vetoed Core. A 12 year old child can create and alternative implementation and we can collectively veto core. Core only has power insomuch as we give them power and it can be taken away quickly in a moments notice.
I'll forego the introductory insult. You're right in explicit terms, I was speaking in practical terms. What you describe may be exactly what will happen, aside from the 12 year old child part and swapping an overambitious BIP101 with BIP102.
Quote
Soft forks don't require consensus.
They require consensus with adoption. If you don't upgrade you don't adopt segwit.
And your former full node is knocked back to SPV+ mode without your request or permission.
Quote
Do you know what happens to the (real, verifying) node count when segwit happens?
Sure... but let me guess a few of your disagreements. Soft forks are voluntary but than the old nodes won't get the lower fees and won't be able to verify properly new segwit txs making them obsolete. A soft fork forces nodes to upgrade to insure they get bug fixes otherwise they will be vulnerable.
Let me address these two concerns:
1) The tx fees comparing now to after segwit on non-upgraded nodes will remain the same unless a fee event occurs which is the exact same scenario with or without segwit. If you don't like the bundling of the other features with capacity improvement than that is what other implementations are for.
2) We are discussing open source code here, which means we can take all the bugfixes and backpatch them to previous versions so they remain segwit free and secure.
A hard fork is the honest way to force nodes to upgrade. A soft fork is a way to break them and suggest they upgrade.
1) Segwit isn't optional for a full node. And it gives only 0.4 to 0.75MB gain for a full bushel of complexity via an opcode hack.
2) We are talking open source code here where miners can get the modest increase in max_block_size they requested without all the extra "benefits", Classic.