pull down to refresh
I think this is a terminology issue rather than a disagreement. It’s a soft fork. Existing nodes would not need to upgrade to remain interoperable with BIP110, if it got adopted. If BIP110 had majority support, nodes would follow along just fine. Only miners would, but that’s normal for soft forks. Soft forks enacted by a hashrate minority do lead to a permanent chainsplit.
Image from this explanation on BSE
The BIP110 nodes will reject non-conforming nodes after the August fork date.
Usually nodes would disconnect peers that offer an invalid block, so I suspected the same in the past, but some RDTS proponent informed me that RDTS explicitly allows peers to offer blocks that would be valid under the old rules, so I don’t think the RDTS nodes will disconnect from the P2P network immediately.
Then for good measure, they hard-fork themselves again when they revert their previously added filtering rules.
I disagree with this characterization. Adding more restrictions is a soft fork. Adding restrictions with a limited time frame is still a restriction, not a loosening of rules.
Terminology is extremely important if you want to have meaningful communication.
Soft- vs. hard- fork debates are always a bit unclear. Generally yes, making the rules more strict is a soft-fork and making the rules less strict is a hard fork. But I would argue the test should be: Do existing nodes need to upgrade to remain interoperable with the nodes running the new software? If yes, then that's a hard-fork.
From what I gather, the BIP110 fork would be a hard-fork for two reasons. The BIP110 nodes will reject non-conforming blocks after the August fork date. So they effectively hard-fork themselves off the network. Then they hard-fork themselves again when they revert their previously added filtering rules.