> IIRC from the CASPER blog posts, the solution is simply to not let the validators reverse history beyond a certain point. I think that was about 2000 blocks or so. After that point a client won't accept an alternate history.
This doesn’t solve the boostrap problem: how do new clients know which fork to choose? PoS is an algorithm that takes a chain as input, and outputs who gets to build the next block. The problem, however, is deciding which chain to give this function as input in the first place — deciding who gets to mine the next block in a chain is fairly easy, agreeing on which chain to choose in the first place is the hard part.
> Not necessarily. Again, CASPER, an attacker who violates some of the consensus rules will loose their entire stake over time (heavy penalties), so behaving is the most profitable option.
They will only lose their stake on a fork, that includes the proof of their violation (because stakers have no incentive to include the proof in the chain they control). Which, again, brings us back to the initial issue: how do clients, who want to join the network, decide which fork to follow?
>This doesn’t solve the boostrap problem: how do new clients know which fork to choose
Google "weak subjectivity". In short; they don't. The user supplies initial consensus. It's also fairly okay if the clients come with a baked in blockhash to start from, you only need to update that once every quarter or so to keep it current.
If an attacker would poison a chain, for example by censoring it, the network can fairly easily slash his stake (this is allowed as part of the protocol) and start a new chain. You only need to point the client at it.
That is, an attacker can only operate while they have both the proof-of-stake consensus and the social consensus. If they loose either, they loose everything.
This doesn’t solve the boostrap problem: how do new clients know which fork to choose? PoS is an algorithm that takes a chain as input, and outputs who gets to build the next block. The problem, however, is deciding which chain to give this function as input in the first place — deciding who gets to mine the next block in a chain is fairly easy, agreeing on which chain to choose in the first place is the hard part.
> Not necessarily. Again, CASPER, an attacker who violates some of the consensus rules will loose their entire stake over time (heavy penalties), so behaving is the most profitable option.
They will only lose their stake on a fork, that includes the proof of their violation (because stakers have no incentive to include the proof in the chain they control). Which, again, brings us back to the initial issue: how do clients, who want to join the network, decide which fork to follow?