Surely you are aware that what you are proposing is vastly different from the way soft forks have historically worked.
Yes, it is different. It’s different because the future network upgrade to larger blocks includes a loosening of the consensus ruleset whereas previous upgrades have included a tightening of the rule set. (BTW—this is not my proposal, I am describing what I have recently learned through my work with Bitcoin Unlimited and discussions with miners and businesses).
With a tightening of the rule set, a hash power minority that has not upgraded will not produce a minority branch; instead they will simply have any invalid blocks they produce orphaned, serving as a wake-up call to upgrade.
With a loosening of the consensus rule set, the situation is different: a hash power minority that has not upgraded will produce a minority branch, that will also drag along non-upgraded node operators, leading to potential confusion. The idea behind orphaning the blocks of non-upgraded miners was to serve as a wake-up call to upgrade, to reduce the chances of a minority chain emerging in the first place, similar to what happens automatically with a soft-forking change. If one's worry is a chain split, then this seems like a reasonable way to reduce the chances of that worry materializing. The Level 3 anti-split protection takes this idea one step further to ensure that if a minority branch does emerge, that transactions cannot be confirmed on that branch.
First of all, the bar for miners being on the new chain is extremely high, 95%.
I’m very confident that most people do NOT want a split, especially the miners. The upgrade to larger blocks will not happen until miners are confident that no minority chain will survive.
Second of all, soft forks make rule restrictions on classes of transactions that are already non-standard so that any non-upgraded miners are unlikely to be including txs in their blocks which would violate the new rules and should not have their blocks orphaned even after the fork.
I agree that the soft-fork mechanism usually works well. I believe this mechanism (or perhaps a modified version of it) to increase the block size limit will likewise work well. All transactions types that are currently valid will be valid after the upgrade, and no new types of transactions are being created. The “block-size-limit gene" of network nodes is simply evolving to allow the network to continue to grow in the way it has always grown. (If you’re interested, here is my talk at Coinbase where I discuss this:
https://www.youtube.com/watch?v=pWnFDocAmfg)
Finally, soft forks are designed to only be used when there is a very wide community consensus and the intention is not to overrule anyone's choice to remain on the old rules but to ensure the security of nodes that may have neglected to upgrade. Obviously it is impossible to draw a bright line between users who intentionally are not upgrading due to opposition and users that are just being lazy. But in the case of a proposed BU hard fork it is abundantly clear that there is a very significant fraction, in fact likely a majority of users who intentionally want to remain on the old rules.
My read is completely different. I still have never talked with a person in real life who doesn’t want the block size limit to increase. Indeed, I have met people who worry that Bitcoin Unlimited is “trying to take over”—and thus they are worried for other reasons—but this couldn’t be further from the truth. For example, what most people within BU would love to see is a simple patch to Bitcoin Core 0.14 that allows node operators to adjust the size of blocks their nodes will accept, so that these node operators can follow consensus through the upgrade if they choose to.
This is not a fight about “Core vs. BU”; Bitcoin’s future is one of “genetic diversity” with multiple implementations, so that a bug in one doesn’t threaten the network as a whole. To me it seems this is largely a fight about whether node operators should be easily able to adjust the size of blocks their nodes accept. BU makes it easy for node operators to accept larger blocks; Core doesn’t believe users should have this power (outside of recompiling from source, which few users can do).
As a Bitcoin user I find it abhorrent the way you are proposing to intentionally cripple the chain and rules I want to use instead of just peacefully splitting.
Once again, this is not my proposal. I am writing about what I have come to learn over the past several weeks. When I first heard about these ideas, I was initially against them too. They seemed harsh and merciless. It wasn’t until I got out their and started talking to more people in the community that the rationale started to make sense to me: the biggest concern people had was a chain split!
So I guess the “ethics” here depend on the lens through which one is looking. People who believe that an important outcome of the upgrade to larger blocks is to avoid a blockchain split may be more favourable to these ideas than people who want the upgrade to result in a split (or are OK with a split), as it sounds like you do (is this true that you’d rather split than accept blocks with more than 1,000,000 bytes of transaction information in them? Sorry if I misunderstood).
But if one's intention is to split and not follow the majority hash power when blocks become larger, then why not change the proof-of-work? This would certainly result in a peaceful splitting, as you said you desire.