[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.

[yanmaani]

> 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.

But you don't know who's honest - you may as well be saying the real chain lost all the dishonest verifiers.

[clolege]

Exactly - that's where statistical analysis (like fakespot) comes in.

For each chain you'd be able to look at the age, stake & historical participation level of the post-fork participants and get a pretty good idea which (if either) of the chains is real. The absence of honest participants should look a lot different than the absence of dishonest ones.

Granted, this method is not nearly as simple as checking the number of 0s on a hash, but I would imagine it to be quite difficult to circumvent.

[randomNumber7]

How do you know what are honest verifiers and wallets?

[clolege]

You any specific verifier/wallet, you won't - but the fake chain will have 0 uncompromised actors after the fork.

Which means that large stakeholders suddenly stop verifying blocks. Long-term active wallets stop transacting.

The same might be true for both chains after the fork, but I would imagine the fake one would have a larger change in participation (weighting older wallets and larger stakes) than the real one.

[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.

[yanmaani]

None of this actually refutes my point. You're just suggesting that the fact that PoS is incapable of producing a consensus is outweighed by it allegedly being more decentralized. Be that as it may, it's not relevant to this thread.

Is it even true? Steemit had the exchanges do a hostile takeover, because everyone was staking through them.