<p>Note that there is a new and better paper about this topic by Aviv Zohar et al. - <a href="http://arxiv.org/pdf/1507.06183v1.pdf" rel="nofollow">http://arxiv.org/pdf/1507.06183v1.pdf</a>.</p>

<p>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.</p>

CC BY-SA 3.0
2015-07-27T07:02:23.773Z
2015-07-27T07:02:23.773Z
Meni Rosenfeld
<blockquote>
  <p>Is the attack really practical?</p>
</blockquote>

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

<ul>
<li><p>It costs nothing (or close to nothing compared to mining pool revenue) to run a sybil attack.</p>

<p>From the paper:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<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.</p></li>
<li><p>Blocks propagate near-instantly.</p>

<p>From the paper:</p>

<blockquote>
  <p>We assume block propagation time is negligible compared
  to mining time, as is the case in reality. </p>
</blockquote>

<p>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.</p></li>
</ul>

<blockquote>
  <p>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")</p>
</blockquote>

<p>No. This was discussed <a href="http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03134.html" rel="nofollow">on the mailing list</a>: </p>

<blockquote>
  <blockquote>
    <p>The suggested change is actually very simple (minutes of coding) and
    elegant and addresses precisely the identified problem.</p>
  </blockquote>
  
  <p>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.</p>
  
  <p>Also, their solution doesn't really address the problem they bring up, it
  just changes the size of the threshold required.</p>
</blockquote>

CC BY-SA 3.0
2015-06-25T23:56:58.370Z
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
CC BY-SA 3.0
2015-06-26T07:12:10.470Z
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
CC BY-SA 3.0
2015-06-26T08:42:37.290Z
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
CC BY-SA 3.0
2015-06-25T21:51:59.660Z
2015-10-25T19:49:47.587Z
2015-10-25T19:49:47.587Z
Nick ODell
<p>The <a href="http://arxiv.org/pdf/1311.0243v4.pdf" rel="nofollow noreferrer">Majority is not enough</a> 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.</p>

<p>I have read about the attack <a href="https://bitcoin.stackexchange.com/questions/14326/colluding-miners-attack-is-the-bitcoin-protocol-compromised">here</a> and <a href="https://bitcoin.stackexchange.com/questions/23798/does-selfish-mining-actually-give-an-advantage-in-the-absence-of-transaction-fee">here</a>, however, I didn't find answers of my questions:</p>

<ul>
<li>Is the attack really practical?</li>
<li>Have bitcoin developers applied the solution proposed in the paper? (If yes, why the wiki is not updated? The <a href="https://en.bitcoin.it/wiki/Block_chain" rel="nofollow noreferrer">wiki</a> states: "generating nodes build onto whichever one of the blocks they received first")</li>
<li>Have bitcoin developers applied another solution for the problem? (The solution proposed in the paper does not solve the problem completely) </li>
</ul>

<p><strong>EDIT:</strong> </p>

<p><em>why mining on both chain forks uniformly would increase the required mining power for a selfish mining attack?</em></p>

<p>Mining on both chain forks uniformly is a solution to <em>sybil attack</em> 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.</p>

<p>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. </p>

CC BY-SA 3.0
2015-06-26T08:46:31.013Z
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
CC BY-SA 3.0
2015-06-26T08:57:58.307Z
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.
Tail of Godzilla
CC BY-SA 3.0
2015-06-26T09:01:02.583Z
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
CC BY-SA 3.0
2015-06-26T09:56:55.610Z
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
<blockchain-fork><bitcoin-core-development><academic-research><selfish-mining>
Have bitcoin developers applied the solution for selfish miner attack?
Tail of Godzilla
# Have bitcoin developers applied the solution for selfish miner attack?

(Asked by: username_0 on 2015-06-25)

The [Majority is not enough](http://arxiv.org/pdf/1311.0243v4.pdf) 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](https://bitcoin.stackexchange.com/questions/14326/colluding-miners-attack-is-the-bitcoin-protocol-compromised) and [here](https://bitcoin.stackexchange.com/questions/23798/does-selfish-mining-actually-give-an-advantage-in-the-absence-of-transaction-fee), 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](https://en.bitcoin.it/wiki/Block_chain) 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.

**Tags:** blockchain-fork, bitcoin-core-development, academic-research, selfish-mining

> **Comments:**
> **username_1**: 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.  
> **username_0**: 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.  
> **username_0**: 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.  
> **username_1**: 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.  

---

## 2 answers

### Answer by username_2 on 2015-07-27. Score: 3 | Accepted answer

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.


---

### Answer by username_3 on 2015-06-25. Score: 2

> 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](http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03134.html):

> > 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.

> **Comments:**
> **username_0**: Thanks username_3. 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.  
> **username_0**: 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%**.  
> **username_1**: 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.  

---

