Skip to content
This repository has been archived by the owner on Oct 31, 2023. It is now read-only.

Slashing in EC #32

Closed
sternhenri opened this issue Jan 24, 2019 · 5 comments
Closed

Slashing in EC #32

sternhenri opened this issue Jan 24, 2019 · 5 comments
Assignees
Labels
EC help wanted External collaboration required or helpful key-todo launch-critical Required for launch P1 Medium priority

Comments

@sternhenri
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

Related to #30

@sternhenri sternhenri changed the title Slashing in Filecoin Slashing in EC Jan 24, 2019
@sternhenri sternhenri transferred this issue from filecoin-project/research Jan 24, 2019
@sternhenri sternhenri added help wanted External collaboration required or helpful launch-critical Required for launch P1 Medium priority key-todo EC labels Jan 24, 2019
@whyrusleeping
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
EC help wanted External collaboration required or helpful key-todo launch-critical Required for launch P1 Medium priority
Projects
None yet
Development

No branches or pull requests

2 participants