[comex]

Indeed. And even if you posit a PoW currency which never has policy changes, unlike Bitcoin or any other major cryptocurrency…

And you assume that attackers will never have enough computing resources to execute a 51% attack – which could happen because the currency’s value falls enough that people stop mining it, because an extraordinarily well-funded entity decides to attack it, or because someone manages to hack the miners…

Then you do gain the security guarantee that if you see multiple competing branches of the blockchain, you’ll know which branch is the correct one (namely, whichever is longest). However, you’re still relying on phoning your “friends” (nodes you’re aware of) to tell you what blocks exist! If they all keep the true longest branch a secret from you (or, say, someone blocks your Internet connection to the nodes that aren’t willing to do so), then you will think the next longest branch is the correct one.

To be fair, that isn’t the most practical attack. But none of the risks being discussed here are remotely practical. In practice, nobody wants to connect an outdated client to a blockchain network because it risks (a) getting yourself exploited through known vulnerabilities in the client, (b) not working due to backwards incompatible protocol changes or bugs, or (c) missing a hard fork that might have happened over disagreements in policy changes (because there are always policy changes). So you update your client, and that means you have to rely on a “friend” to tell you which software you should be running.

[bhaak]

What you describe is indeed a viable threat in certain conditions.

It's called "Eclipse Attack". But it's a threat for single nodes not for the network as a whole.

[comex]

> But it's a threat for single nodes not for the network as a whole.

Indeed, but the same is true for attacks on "weak subjectivity" proof-of-stake. They're only a threat for nodes that have been disconnected for a long time (months) before they try to reconnect.

[yanmaani]

Except for the part where eclipse attacks can be resolved by simply feeding my node more data (it's not a problem if some of it is lies), while "weak subjectivity" requires recourse to an external authority.

[bshanks]

i don't know as much about this as you, but it seems to me that the attack you describe in the blog post would also require a successful eclipse attack?

My understanding is that the attack you describe involves a cabal of "evil" validators signing some alternate chain (call it the "fake" chain) long after their stake is withdrawn, creating a fork in the distant past. Before they did this, they pretended to be good validators, which meant they signed the "real" chain's blocks and then signed the withdraw transaction. So after the attack, there are two conflicting sets of signatures signed using the evil cabal's private keys; those on the fake chain, and those on the real chain. So anyone in possession of both of these sets of signatures can conclude that the validators in the cabal are "evil", and then they can see that once the cabal's support is removed from consideration, the real chain had more valid validator support (at the time of the fork, in the distant past). If this line of reasoning is correct, that suggests that anyone who is aware of both sets of signatures can identify the real chain?

[yanmaani]

> So after the attack, there are two conflicting sets of signatures signed using the evil cabal's private keys; those on the fake chain, and those on the real chain. So anyone in possession of both of these sets of signatures can conclude that the validators in the cabal are "evil", and then they can see that once the cabal's support is removed from consideration, the real chain had more valid validator support (at the time of the fork, in the distant past).

I think this is where you get the problem - if you just have two sets of signatures, how do you tell which is legitimate and which one isn't? How do you conclude in which set the cabal was lying?

An eclipse attack is so named because it requires you to keep all the light out so they're kept in the dark. But here, since there's no internal mechanism to tell the two chains apart, you don't only need the accurate information, but also outside information about which one is accurate.

[clolege]

> I think this is where you get the problem - if you just have two sets of signatures, how do you tell which is legitimate and which one isn't? How do you conclude in which set the cabal was lying?

I feel like you should be able to deduce it from the distribution of participation after the fork, right?

The “fake” chain would lose all honest verifiers (and all transactions from honest wallets?) which seems like it would be pretty detectable with simple statistical analysis. Staked nodes not participating (and active wallets not transacting) becomes less and less likely the longer the post-fork chain is.

[comex]

If you actually see two conflicting chains (either proof-of-work or proof-of-stake) with large numbers of people vouching for both, then the correct chain is not necessarily "whichever one is longer". Well, it could be, for you; "correct" is subjective. But by assumption in this scenario, a large number of people disagree, and you might want to transact with some of them. There is no way for software to decide this objectively; it has to ask the user to decide based on factors external to the network.

Where proof-of-work really does have an advantage is that you can more easily distinguish that scenario from the scenario where either one of the chains is actually a Sybil attack, i.e. a single attacker pretending to be a large number of people. Similarly, if you only see a single chain, with proof-of-work you can try to detect an eclipse attack (which implies a Sybil attack) by seeing if the hashrate has gone down dramatically.

That's a real advantage. I don't think it's even close to enough to mitigate proof of work's disadvantages, especially since the circumstances where it would practically come into play are extremely unlikely, but it's not nothing.

However, it's undermined by the fact that proof of work naturally encourages centralization. Bitcoin is centralized enough that it's not completely impossible for the vast majority of the hashrate to end up on one side of a fork (either soft or hard), while the vast majority of users and developers end up on the other side. (To be clear, this is very, very unlikely to actually happen, but so are all of the attacks we're talking about.) If this happens, the objective proof-of-work standard will side with the miners, but not with the people you actually want to transact with.

Of course, a proof of stake currency can also suffer a schism, but there is (probably) less tendency for stakers to be centralized, and if a schism did occur, at least the client wouldn't provide a false sense of objectivity.

[rocqua]

Note that for bitcoin, because of soft forks, you could take a really old client and still find the 'true' chain.