This is why I called it a "generalized" softfork, since it has properties of softforks but has the power of a hardfork (in this case). It is sort of an "in-between" kind of fork.
How does this have properties of a soft fork? It is missing the key point of a soft fork, old clients are still able to use Bitcoin after the fork. This is a hard fork since I cannot run current software after this fork and still be able to send and receive transactions and use it as I do now.
Since this is a (generalized) softfork, there is a very strong incentive for miners to upgrade to the new rules (orphaned blocks). So this should not happen provided the majority hash power are on board when the fork occurs.
However, if it *did* happen, then this is a disaster no matter how the fork is designed. Either the old (longer) chain is rejected as invalid, or there is a very large reorg undoing many multi-confirmation transactions.
There is already a strong incentive to upgrade with a normal soft fork. Miner's blocks will be orphaned if they don't upgrade.
And such forks have happened before, see the July 4th forking incident:
https://bitcoin.org/en/alert/2015-07-04-spv-miningA softfork is the same as a 51% attack against the old rules. The generalized softfork is no different. I think DannyHamilton understands this.
I think this is different. What you propose is simultaneously mine on two different blockchains, the old and new one. This is a 51% attack on the old chain as it just produces a bunch of empty blocks thus preventing confirmations. In a normal soft fork, this doesn't happen and other miners can extend that old chain, they just don't have any incentive to do so. Again, see the July 4th forking incident for an example of miners extending the old chain. Your proposal wouldn't allow that to happen, but old clients would only be able to use the old chain, so it is a hard fork.
If Danny understood it, then I invite him to explain it to me since he is much better at explaining than you are.
