3 ms·

But...if you no longer have value on the network, doesn't that mean you no longer have enough stake to control the network?

inter_netuser 5y ago
a coalition of wealthy interests can trivially dictate the consensus rules with very little to no recourse on your part. Even if the chain splits, they can maintain their share on both chains, and even suppress the minority chain. In PoW miners risk going bankrupt overnight for egregious behaviour like that. I'd like to see how one defines "slashing" programmatically that is impartial, works algorithmically, and does not have edge cases that can lead to catastrophic failures without handwavy assumptions that every single PoS network has today.
- dawnbreez 5y ago
  No, no, back up a second. The argument being made in the parent comment is that once there is one entity with enough stake in the network to dictate where it goes, they can just pull out before tanking the network. But my understanding was that you can only have enough stake in the network to make decisions...by having that stake in the network. If you un-stake your crypto and cash out, by definition, you no longer have any stake in the network. If you no longer have any stake, how do you have a controlling stake?
  - newaccount74 5y ago
    If you had a controlling stake in the past, couldn't you just rewrite history to make it seem like you still have stake?
- delaaxe 5y ago
  You can look up how Ethereum's beacon chain implements slashing
  - inter_netuser 5y ago
    Yep, isn't it great to get slashed for being DDoSed? Amazing breakthrough, realy. Now ddos blackmail can be actually measured in money. At least you could point to avalanche or something else that's better constructed. Eth is a dinosaur at this point, albeit with the fattest treasury.
    - DennisP 5y ago
      If you go offline the penalties are very small. You can be offline a third of the time and break even. The real penalty happens if you send conflicting messages, and even that's not too severe unless a lot of other nodes do it at the same time.
rocqua 5y ago
You can fork far in the past, before you cashed out. Any new entrants into the network will not be able to distinguish your fork from the real chain. You cannot be slashed for this in the real chain because you already cashed out your stake there. This 'long range attack' is different from a 50% attack because it doesn't affect nodes that were running before the attack happened. But a situation where new entrants into the network are uncertain of the 'true' fork is not tenable in the long term. This seems more viable for a value destruction attack than for a double spend. But value destruction can be lucrative for blackmail. It means a coalition of stakers could withdraw their stakes and state "increases the blocksize or suffer a long-range attack".
- bastiantower 5y ago
  Wouldn't anyone then be able to provide proof of that participant having exited? The participant would have generated a signature the moment they exit.
- jaggirs 5y ago
  But why would a new entrant get the chain from a node that already exited, and why would this affect anyone other than the entrant itself? I assume the new entrant is itself liable if it copies the wrong chain, because other nodes will vote against it once it starts operating, so it will make an effort to get the correct chain (maybe by buying it from current nodes and ensuring they all provide the best chain). So maybe you would have some kind of cartel of running nodes that may or may not allow new nodes to enter, but I don't see a critical network-destroyig issue here.
- dlubarov 5y ago
  > But a situation where new entrants into the network are uncertain of the 'true' fork is not tenable in the long term. This is an important point to consider, but it can be mitigated with exit delays. E.g. with Eth2's current settings, if an attacker had 2/3 stake at one point, I believe it would take them 6-7 months to exit all those validators. So while it's true that new entrants must sync from a trusted checkpoint, the checkpoint can be quite old. Let's say my client has a hardcoded list of checkpoints, with a new one added once a month. The client would only accept forks containing all of those checkpoints in their history. It seems like there are two ways an attacker with commit access might try to corrupt this checkpoint list. First, they could try to add bad checkpoints over a period of 6-7 months, until they've fully exited and can safely perform a long-fork attack. This seems impractical, since the bad checkpoints would be noticed by existing node operators (who would get stuck after upgrading their clients), and 6-7 months seems like plenty of time to raise the alarm. Alternatively, an attacker could just delete 6+ good checkpoints, and replace them with 6+ bad ones, all at once. This would violate the convention of adding monthly checkpoints, so it should be easily recognized as a malicious change. One could argue that it might go unnoticed anyway, but sneaking in such a change seems roughly as hard as sneaking in any other clearly-malicious client change.

inter_netuser 5y ago

a coalition of wealthy interests can trivially dictate the consensus rules with very little to no recourse on your part. Even if the chain splits, they can maintain their share on both chains, and even suppress the minority chain. In PoW miners risk going bankrupt overnight for egregious behaviour like that. I'd like to see how one defines "slashing" programmatically that is impartial, works algorithmically, and does not have edge cases that can lead to catastrophic failures without handwavy assumptions that every single PoS network has today.

dawnbreez 5y ago
No, no, back up a second. The argument being made in the parent comment is that once there is one entity with enough stake in the network to dictate where it goes, they can just pull out before tanking the network. But my understanding was that you can only have enough stake in the network to make decisions...by having that stake in the network. If you un-stake your crypto and cash out, by definition, you no longer have any stake in the network. If you no longer have any stake, how do you have a controlling stake?
- newaccount74 5y ago
  If you had a controlling stake in the past, couldn't you just rewrite history to make it seem like you still have stake?
delaaxe 5y ago
You can look up how Ethereum's beacon chain implements slashing
- inter_netuser 5y ago
  Yep, isn't it great to get slashed for being DDoSed? Amazing breakthrough, realy. Now ddos blackmail can be actually measured in money. At least you could point to avalanche or something else that's better constructed. Eth is a dinosaur at this point, albeit with the fattest treasury.
  - DennisP 5y ago
    If you go offline the penalties are very small. You can be offline a third of the time and break even. The real penalty happens if you send conflicting messages, and even that's not too severe unless a lot of other nodes do it at the same time.

rocqua 5y ago

You can fork far in the past, before you cashed out. Any new entrants into the network will not be able to distinguish your fork from the real chain. You cannot be slashed for this in the real chain because you already cashed out your stake there. This 'long range attack' is different from a 50% attack because it doesn't affect nodes that were running before the attack happened. But a situation where new entrants into the network are uncertain of the 'true' fork is not tenable in the long term. This seems more viable for a value destruction attack than for a double spend. But value destruction can be lucrative for blackmail. It means a coalition of stakers could withdraw their stakes and state "increases the blocksize or suffer a long-range attack".

bastiantower 5y ago
Wouldn't anyone then be able to provide proof of that participant having exited? The participant would have generated a signature the moment they exit.
jaggirs 5y ago
But why would a new entrant get the chain from a node that already exited, and why would this affect anyone other than the entrant itself? I assume the new entrant is itself liable if it copies the wrong chain, because other nodes will vote against it once it starts operating, so it will make an effort to get the correct chain (maybe by buying it from current nodes and ensuring they all provide the best chain). So maybe you would have some kind of cartel of running nodes that may or may not allow new nodes to enter, but I don't see a critical network-destroyig issue here.
dlubarov 5y ago
> But a situation where new entrants into the network are uncertain of the 'true' fork is not tenable in the long term. This is an important point to consider, but it can be mitigated with exit delays. E.g. with Eth2's current settings, if an attacker had 2/3 stake at one point, I believe it would take them 6-7 months to exit all those validators. So while it's true that new entrants must sync from a trusted checkpoint, the checkpoint can be quite old. Let's say my client has a hardcoded list of checkpoints, with a new one added once a month. The client would only accept forks containing all of those checkpoints in their history. It seems like there are two ways an attacker with commit access might try to corrupt this checkpoint list. First, they could try to add bad checkpoints over a period of 6-7 months, until they've fully exited and can safely perform a long-fork attack. This seems impractical, since the bad checkpoints would be noticed by existing node operators (who would get stuck after upgrading their clients), and 6-7 months seems like plenty of time to raise the alarm. Alternatively, an attacker could just delete 6+ good checkpoints, and replace them with 6+ bad ones, all at once. This would violate the convention of adding monthly checkpoints, so it should be easily recognized as a malicious change. One could argue that it might go unnoticed anyway, but sneaking in such a change seems roughly as hard as sneaking in any other clearly-malicious client change.