You can fork far in the past, before you cashed out. Any new entrants into the network will not be able to distinguish your fork from the real chain.
You cannot be slashed for this in the real chain because you already cashed out your stake there.
This 'long range attack' is different from a 50% attack because it doesn't affect nodes that were running before the attack happened. But a situation where new entrants into the network are uncertain of the 'true' fork is not tenable in the long term.
This seems more viable for a value destruction attack than for a double spend. But value destruction can be lucrative for blackmail. It means a coalition of stakers could withdraw their stakes and state "increases the blocksize or suffer a long-range attack".
> 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.
But why would a new entrant get the chain from a node that already exited, and why would this affect anyone other than the entrant itself? I assume the new entrant is itself liable if it copies the wrong chain, because other nodes will vote against it once it starts operating, so it will make an effort to get the correct chain (maybe by buying it from current nodes and ensuring they all provide the best chain). So maybe you would have some kind of cartel of running nodes that may or may not allow new nodes to enter, but I don't see a critical network-destroyig issue here.
Wouldn't anyone then be able to provide proof of that participant having exited? The participant would have generated a signature the moment they exit.
This 'long range attack' is different from a 50% attack because it doesn't affect nodes that were running before the attack happened. But a situation where new entrants into the network are uncertain of the 'true' fork is not tenable in the long term.
This seems more viable for a value destruction attack than for a double spend. But value destruction can be lucrative for blackmail. It means a coalition of stakers could withdraw their stakes and state "increases the blocksize or suffer a long-range attack".