4 ms·

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 w

by comex 5y ago

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 5y ago
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 5y ago
  > 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 5y ago
    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 5y ago
      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 5y ago
        > 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.
rocqua 5y ago
Note that for bitcoin, because of soft forks, you could take a really old client and still find the 'true' chain.

by comex 5y ago

bhaak 5y ago

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 5y ago
> 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 5y ago
  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 5y ago
    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 5y ago
      > 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.

rocqua 5y ago

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