> But a situation where new entrants into the network are uncertain of the 'true' fork is not tenable in the long term. This is an important point to consider,

> But a situation where new entrants into the network are uncertain of the 'true' fork is not tenable in the long term. This is an important point to consider, but it can be mitigated with exit delays. E.g. with Eth2's current settings, if an attacker had 2/3 stake at one point, I believe it would take them 6-7 months to exit all those validators. So while it's true that new entrants must sync from a trusted checkpoint, the checkpoint can be quite old. Let's say my client has a hardcoded list of checkpoints, with a new one added once a month. The client would only accept forks containing all of those checkpoints in their history. It seems like there are two ways an attacker with commit access might try to corrupt this checkpoint list. First, they could try to add bad checkpoints over a period of 6-7 months, until they've fully exited and can safely perform a long-fork attack. This seems impractical, since the bad checkpoints would be noticed by existing node operators (who would get stuck after upgrading their clients), and 6-7 months seems like plenty of time to raise the alarm. Alternatively, an attacker could just delete 6+ good checkpoints, and replace them with 6+ bad ones, all at once. This would violate the convention of adding monthly checkpoints, so it should be easily recognized as a malicious change. One could argue that it might go unnoticed anyway, but sneaking in such a change seems roughly as hard as sneaking in any other clearly-malicious client change.