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.
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.
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
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.
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.