Quote from: Vitalik Buterin on May 20, 2014, 11:42:15 AM

One problem I have started to think about a lot about PoS in general is long-range attacks: what if you try to 51% attack a PoS blockchain straight from (or very close to) the genesis block?

To explain this, consider the following. First, suppose that 90% of all coin owners suddenly disappear. Will it be possible at all to generate any more blocks? Suppose yes. Then, an attacker with 10% stake will be able to fork the blockchain at some point 3 years ago, and then let it develop inside a virtual server. After generating a few million cost-free blocks, the attacker now publishes this new chain. How does a new node differentiate between the legitimate chain and the offending fork?

The second problem is long-range nothing-at-stake. Slasher fixes the short-range nothing-at-stake problem, but if a fork does start 50000 blocks ago, then there still is no incentive not to mine on both in parallel. Even with transactions-as-proof-of-stake, transaction senders have the incentive to send conflicting transactions into the other chain in order to double spend themselves. But maybe this issue will turn out to be not that important in practice.

Yes this is a problem that this design does not handle directly. Rather I consider it the sort of catastrophe that is best dealt with by a network operations center. In the case of current Bitcoin, the lead core developers can issue an alert, and mobilize the community to download a new software version. In constrast, enterprise data networks, especially the incumbent financial data networks have network operations centers that rehearse detection of, and recovery from such faults.

This design provides funding for such a center, run in a decentralized manner by autonomous trustless agents to the greatest possible extent.