I am very surprised that they make no reference to this:
Someone clearly didnt do their homework.
The problem with this argument is that it does not take time into account. If a validator from ten years ago double-signs mutually conflicting blocks — that is, publishes a newly signed contradictory counterpart to the block that was confirmed ten years ago — then the history will need to be re-written from that point onwards. The malicious validator’s stake is slashed. Transactions that spend the staking rewards are now invalid, as are transactions downstream from there. Given enough time, the validator’s rewards may percolate to a large part of the blockchain economy. A recipient of coins cannot be sure that all dependencies will remain valid in the future. There is no finality because it is not more difficult or costly to reorganize the far past than the near past.
I’m not an expert in slashing algorithms, but I’m sure slashing only applies in the short-term where the “staked” amounts are locked from being spent? It doesn’t make sense to slash coins that have already been spent and therefore invalidate transactions already made.
Peercoin doesn’t use slashing in any case, so it’s not relevant.
Edit: I see that the argument is focused on long-range attacks and Vitalik’s blog post Nagalim posted highlighted that people might sell their old private keys to provide minting/staking power from some point in history.
Even if the private keys have no currently associated coin balance, the owners may still have an interest in the network. If so, they would not be willing to sell those private keys for an attack unless compensated for any loses expected on the value of those coins.
Also, it would be difficult to source the owners of these keys and many of these keys may be lost. Many private key owners would find the sale of these keys to facilitate an attack morally objectionable even if they no longer have economic interest in the network.
Fundamentally, as Vitalik mentions, the long-range attacks can be thwarted through checkpoints. Hardcoding checkpoints into the software is more useful for a PoS coin than a PoW. When included in the source code, they form part of the protocol that people agree to operate. People can refuse an update if they disagreed with a checkpoint for whatever reason. New users would only care about checkpoints that correspond to the economically active fork which is simple enough to determine.
Attacks made after the last checkpoint may seem possible due to the “nothing at stake” argument, but minters have an interest in preserving the value of their coins so would be unwise to undermine the security of the network. Slashing is perhaps solving a problem that doesn’t need to be solved. Peercoin has survived without it.