Slashing in EC

[sternhenri]

While slashing is currently well specced out, it will need refinement to ensure Filecoin is incentive compatible.

Specifically, there is some issue with undetectable nothing at stake and a potential sybil attack (from @whyrusleeping), so we will need to rework it.

Tracking that work here.

[whyrusleeping]

As a miner, i can simply split up my power amongst many miners in order to avoid the 'no two blocks from the same miner at the same height' slashing condition.

[sternhenri]

Related to https://github.com/filecoin-project/consensus/issues/30

[whyrusleeping]

Okay, here’s a better write up, with (hopefully) a convincing argument of why I no longer think this is a problem.

An attacker with 30% of the power has a 30% chance of mining a block at any given moment. During a fork, an attacker would have a 30% chance of winning on each fork, meaning they could continue to mine on both forks, except for 30% of the time they win, they will win on both chains and have to forgo publishing one of the blocks to avoid being slashed. This means that the miner loses 30% of their expecte rewards, but is still able to mine on both chains. Now, if the miner instead controls two miners each with 15% of the total power in the network, they still have a 30% chance of winning on each fork, but they drop the probability of mining with the same miner at the same time on both chains down to 15% of their winnings (meaning they have to forgo 15% of their ‘successfully’ mined blocks). This continues on down, 3 identities is 10%, 4 is 7.6%, 5 is 6% and so on. So at the end of the day, the miner can mine on both chains with only a minimal loss in potential proceeds.

Now here’s the catch. The above is assuming that every election is an independent random process (even across forks). In expected consensus, we have the idea of a look back parameter that can be used to source randomness and the set of winners from some number of blocks back in the chain. What that means here is that, if our look back parameter is 10, that the same exact miners will always win at the same time on both chains, for at least 10 blocks. So even if you have many Sybils, the same Sybil will always win at the same time on both chains. The only way that you could pull off a fork at all here, would be if each of those ten rounds produced multiple winners and, and at each time step, one of the winners decided to mine on fork A, and the other on fork B. The probability of this happening for some number of rounds goes down exponentially. (Though we need to factor in the fact that miners can create null blocks)

[sternhenri]

Yes yes yes. This is also why we think lookback solves this.

I think there is one inaccuracy in the paragraph, namely:

• "the 30% of the time they win, they will win on both chains" -- not true with no lbp.

To make your point another way: lbp allows leader election to operate under a global lottery (as opposed to local lottery), thereby removing "choice" from an adversarial miner in terms of potential forks and making it unlikely that they consistently mine across chains.

Our sim shows the same, even with null blocks!

[sternhenri]

Are we laying Why r u splitting to rest @ZenGround0 :/ :b