The key point of countersign, vs any authentication scheme proposed elsewhere that I’m aware of is that a would-be MITM can’t detect if the parties are authenticating or not. This means that once its deployed and reaches some small threshold of use the MITM must either choose between being detected or not MITMing any meaningful amount of traffic at all.
Now for the attacks discussed here maybe we could imagine that the attackers wouldn’t bother MITMing anyways, they’d just sever links to selectively partition the network at a time of their choosing. For example, carve off a majority hashpower to carry their reversal transaction and partition their target with a minority to confirm a payment to be reversed.
But if they’re actively that should be detectable through connection loss.
When we were thinking about countersign we imagined that a transacting node with good security practices would establish a couple peers that were authenticated– then have their wallet treat transactions without a lot of depth as unconfirmed if too many of their authenticated peers were unreachable.
Regarding diversity, there are perhaps other ways to accomplish that. For example, if many people ran observation points and published signed messages of the chain tip(s) they think are leading… then these observations would give you a diverse view. Unfortunately I don’t think mechanisms like this can actively be used in consensus (e.g. to pick your own chain tip) without creating vulnerabilities like those signers censoring some participants blocks. But they presumably can be used to cause something to fail safer (e.g. regarding things as unconfirmed without recent observations or observations that suggest a better chain may exist).