Have bitcoin developers applied the solution for selfish miner attack?

The Majority is not enough paper proposed an academic and somehow practical attack to Bitcoin mining system based on creating hidden forks. The paper claims that if miners work on whichever fork they received first, the attack can be executed by very small pool. Their proposed solution is: "when a miner learns of competing branches of the same length, it should choose which one to mine on uniformly at random". However this solution does not solve the problem completely, it just increases required size of the pool which want to execute the attack.

I have read about the attack here and here, however, I didn't find answers of my questions:

Is the attack really practical?
Have bitcoin developers applied the solution proposed in the paper? (If yes, why the wiki is not updated? The wiki states: "generating nodes build onto whichever one of the blocks they received first")
Have bitcoin developers applied another solution for the problem? (The solution proposed in the paper does not solve the problem completely)

EDIT:

why mining on both chain forks uniformly would increase the required mining power for a selfish mining attack?

Mining on both chain forks uniformly is a solution to sybil attack of the selfish miners. Selfish want to force other miners to work on their fork, so they create a significant number of zero-power miners to the Bitcoin miner network, as their sensor. When one of their sensors senses a new valid block, all sensors broadcast the fork of the selfish miners. Therefore, more than half of miners (nearly all of them) would work on selfish miners fork.

Note that, the sybil attack and their proposed solution is minor part of the attack. The main attack could be executed without running sybil attack and even in the case of applying their proposed solution, if the selfish miners have 33% of mining power.

Tail of Godzilla

Posted 2015-06-25T20:32:45.657

Reputation: 297

From your summary, it is not clear, why mining on both chain forks uniformely woudl would increase the required mining power for a selfish mining attack. If anything, it would decrease it, because if the selfish miners would only support their own fork and the others would half their mining power to both branches the selfish branch would have most mining power support. Also, the proposed fix seems to completely mess up the incentive structure of mining, because people could just continue mining at previous height, as even a late block might build a longest chain. – Murch – 2015-06-26T08:46:31.013

All in all, the sybil attack, and their proposed solution is minor part of the attack. The main attack could be executed without running sybil attack and even in the case of applying their proposed solution, if the selfish miners have 33% of mining power. That is why I add my last question to the question list. – Tail of Godzilla – 2015-06-26T09:01:02.583

Alright, with the sybil attack explanation it makes sense to me. It would be nice, if you could edit your post to clarify it in the question post as well. Thank you. – Murch – 2015-06-26T09:56:55.610

Answers

Note that there is a new and better paper about this topic by Aviv Zohar et al. - http://arxiv.org/pdf/1507.06183v1.pdf.

None of the solutions suggested have been implemented yet. The attack is significant enough that some solution will need to be found, but that's up to researchers, not developers.

Meni Rosenfeld

Posted 2015-06-25T20:32:45.657

Reputation: 18 542

Is the attack really practical?

Eh... maybe. The whitepaper you linked makes two assumptions, and it's not clear how well those hold up in practice.

It costs nothing (or close to nothing compared to mining pool revenue) to run a sybil attack.

From the paper:

Because selfish mining is reactive, and it springs into action only after the honest nodes have discovered a block X, it may seem to be at a disadvantage. But a savvy pool operator can perform a sybil attack on honest miners by adding a significant number of zero-power miners to the Bitcoin miner network. These virtual miners act as advance sensors by participating in data dissemination, but do not mine new blocks. (Babaioff et al. also acknowledge the feasibility of such a sybil attack [10]). The virtual miners are managed by the pool, and once they hear of block X, they ignore it and start propagating block P.

There are around 5k full nodes, so to significantly alter how blocks are relayed, you'd need to add a decent number of them. This is a fixed cost, and it imposes a lower bound on the amount of hashpower necessary to make this profitable.
Blocks propagate near-instantly.

From the paper:

We assume block propagation time is negligible compared to mining time, as is the case in reality.

That's not necessarily true. Miners today produce lots of orphan blocks, and it seems like running a selfish mining attack would increase the orphan rate.

Have bitcoin developers applied the solution? (If yes, why the wiki is not updated? The wiki states: "generating nodes build onto whichever one of the blocks they received first")

No. This was discussed on the mailing list:

The suggested change is actually very simple (minutes of coding) and elegant and addresses precisely the identified problem.

Disagree. Unless I'm misunderstanding what they propose, their suggested change would mean anyone could broadcast a newly discovered block at any point and have a 50% chance of being the winner. That is a fundamental change to the dynamics of how Bitcoin works that would require careful thought and study.

Also, their solution doesn't really address the problem they bring up, it just changes the size of the threshold required.

Nick ODell

Posted 2015-06-25T20:32:45.657

Reputation: 26 536

Thanks Nick. But none of the assumptions are required for running successful attack. If the first assumption would be violated, it only increase size of the threshold required for running attack (which is 33% of total hash power of the network in the worst case). Second assumption is for their simulation. It is not about their mathematical analysis. – Tail of Godzilla – 2015-06-25T23:56:58.370

About the post of mailing list: I think the developer did not understand the attack completely. Their suggested change would NOT mean anyone could broadcast a newly discovered block at any point and have a 50% chance of being the winner. If anyone can do it, the size of the threshold required for running attack would be 25%. However, if no one can do it, the threshold would be 33%. – Tail of Godzilla – 2015-06-26T07:12:10.470

It would help if you would mark clearly what is what. I assume that the bullet points are your summaries and the quotation blocks below that are from the whitepaper, but it would help if you cited it as such. – Murch – 2015-06-26T08:42:37.290