Warren Buffet buys up 70% of the network, induces a network partition, and then double spends it all, signing both transaction histories.
By the time he’s caught, he’s converted 2x the value of the POS network to POW bitcoins.
Replace “warren buffet” with “crypto exchanges selling bundled securities”, and the above is not just plausible, it’s inevitable.
The same scam has been run over and over again with conventional banks (who are inevitably bailed out on top of getting to take the money and run), POS just changes the nature of the obscure underlying financial instruments.
This risk can be mitigated:
1. The network should halt if a fork is detected. A fork with more than 66% of the stake behaving maliciously means a fundamental trust assumption of the network has been violated. Stop everything! Let humans figure out what is going on. I'm not saying every PoS system WILL halt under these circumstances, but as a countermeasure they SHOULD be designed to halt and value safety over partition resilience. Thus, an attacker forking a PoS must never allow parties to see either side of the fork. If a party notices a fork occurs, they will halt and can't be double spent against.
2. Following from 1, how do you prevent parties from communicating and discovering that a fork is occurring? Are you a tier-1 ISP and can control all internet traffic? You can defend against such attacks by making it very hard to hide the presence of a fork via redundant communication mechanisms. For instance the Bitcoin blockchain is broadcasted via satellite, a PoS blockchain could do that as well.
3. Additionally you can require that stakers lock their stake for long periods of time e.g., 6 months. This means that if an attacker wants to perform this attack and truly have nothing at stake they must cause a fork in the chain before the 6-months ago mark. Parties who are up to date with the latest chain are not vulnerable since they have already accepted the consensus history of chain. New parties who are syncing for the first time would be vulnerable, however clients could be programmed to have hardcoded 6th month checkpoints or clients could check block explorers and halt if a fork is detected.
Yeah, but you're glossing over an important detail: It's not 66% of the stake that has to be good, it's 66% of anyone who has ever staked. In PoW, I only need to trust the miners of today to tell me the truth about what happened today. In PoS, I need that, plus the miners of yesterday, plus the miners of a year ago, plus ..., in perpetuity.
> New parties who are syncing for the first time would be vulnerable, however clients could be programmed to have hardcoded 6th month checkpoints or clients could check block explorers and halt if a fork is detected.
Right, maybe you can elaborate on this. Is checking block explorers a decentralized or trustless solution to, well, anything?
I don't quite get that. As far as I understand it the "nothing at stake" problem works by a malicious party inducing a fork, one of which they double-spend in. Since it's in the best interest for everyone else to mine both forks, you can force your double-spend fork to become the longest chain by only validating the double-spend fork.
This means you have to trust that nobody part of your current chain has double-spent in this way. But isn't this the same as in PoW where you have to trust that nobody has launched a 51% attack to disrupt the network in the past?
Also, can't you just prevent people from mining all forks? I.e. for becoming a validator you have to deposit X as a security beforehand and you can only earn at most X via staking (so it is in the history before you can attack with nothing at stake). If it is recognised that you mine on more than one fork at a time, you lose the security deposit you gave before the fork. X goes to the person who found the fork, incentivising that the mallicious fork is identified on all forks (miners on competing forks are incentivised to look at all forks and quickly add the mallicious fork detection for their own benefit). If you want to retrieve your security and money earned, you have to announce this on all forks (you immediatly seize to be a validator). You are only allowed to retrieve the funds, if it is confirmed on all forks, or the forks are sufficiently behind the longest chain. This allows everybody ample time to look for dual-fork work and also incentivizes rapid solution of forks.
Yes, modern proof-of-stake algorithms work this way. The caveat is that at some point (on the order of months later) the security deposit is refunded, and at that point you can lie about the past without consequence. But this is a limited attack: you can only successfully lie to someone who has been offline since you were a staker, or else they would already have a record of the real successor chain (which now has a new set of stakers, who themselves still have their security deposit deposited).
Like, this is trivially solved with a central authority (e.g. have some trusted core developer every day publish a signed message saying "this is the real successor chain"), but it does enable that central authority to arbitrarily bless a fake ex-staker's fork.
Note that in Bitcoin you can have a fork in which both chains have equal length. The idea is that eventually the longest chain will be established, but if say 90% of the mining is malicious that malicious miner could ensure that most of the time both chains are of equal length.
With a PoS fork you can ask, which fork has the most amount of stake voting for it. An attacker that controls enough stake might be able to balance the total stake vote in the same way as a malicious miner could on Bitcoin.
In both cases if the core security assumption of the blockchain is violated, that blockchain should halt until that assumption is made sound again. If someone orphans the last two years of Bitcoin's blockchain something has gone horribly wrong. The fact that Bitcoin now switches to the longest chain doesn't actually address the problem that two years of transactions may have been rendered invalid.
What does this mean in practice? Who are these humans? When can the network get going again? Would a consensus rule change be part of it, and what type of changes would be allowed in that situation?
It sounds hard to manage this type of maintenance breaks in a trustless way. Surely consensus rule changes during outages should not be handled any differently than changes when under normal operations.
> clients could be programmed to have hardcoded 6th month checkpoints
Who signs these checkpoints? Once you have established the trust required for checkpointing the entire blockchain regularly, wouldn't it be much easier to checkpoint every block instead and in an instant do away with all the hard problems of blockchain networks?
We have a bunch of examples of this happening in practice. The humans are usually a mix of the developers, parties important to consensus (miners, stakers) and big ecosystem players.
> It sounds hard to manage this type of maintenance breaks in a trustless way.
When solving a problem that violates your core security assumption you are only longer in the world of security definitions. It doesn't really make sense to talk about "trustlessness". If the protocol is busted, you need to find a solution and get enough people on board with that solution that you can upgrade the protocol.
> Once you have established the trust required for checkpointing the entire blockchain regularly, wouldn't it be much easier to checkpoint every block instead and in an instant do away with all the hard problems of blockchain networks?
The checkpoints aren't trusted for safety but instead for availability. Instead you should think of them like alarms that "something has gone horribly horribly wrong, stop everything, don't transact, don't move, don't touch anything, pull the ebrake."
tl;dr Much like the fuse box in your house, my view is that checkpoints should turn safety failures (electrical fires) into availability failures (electricity is shut off).
In practice, among the people who once staked large amounts of a proof-of-stake currency, most of them will probably continue being invested in its ecosystem moving forward. Even if they can't be personally punished for lying about the past, a successful history split would likely reduce the community's confidence in the currency, and thus its market value. Most of those people are also emotionally invested in the ecosystem and would not want to dishonestly subvert it. There will be exceptions. But to create an alternate history you need to subvert not just one validator, but most validators (or rather, validators who together control most of the currency being staked).