Prevent 'Selfish mining' vulnerability (Eyal & Sirer 2013) #3201

issue nu11gravity opened this issue on November 5, 2013
  1. nu11gravity commented at 6:01 AM on November 5, 2013: none

    Put simply: "minority can earn revenue in excess of their contribution" as written in this paper: http://arxiv.org/abs/1311.0243

    Surprisingly, the return from keeping your mined block secret for a few minutes outweighs the risk of someone beating you to it (with a big enough pool, such as the ones that already exist).

    The paper suggests a solution (should take less than 5 minutes):

    "We propose a simple, backwards-compatible change to the Bitcoin protocol to address this problem and raise the threshold. Specically, when a miner learns of competing branches of the same length, it should propagate all of them, and choose which one to mine on uniformly at random. In the case of two branches of length 1, as discussed in Section 4, this would result in half the nodes (in expectancy) mining on the pool's branch and the other half mining on the other branch. This yields Y = 1/2, which in turn yields a threshold of 1/4. Each miner implementing our change decreases the selsh pool's ability to increase through control of data propagation. This improvement is independent of the adoption of the change at other miners, therefore it does not require a hard fork. This change to the protocol does not introduce new vulnerabilities to the protocol: Currently, when there are two branches of equal length, the choice of each miner is arbitrary, eectively determined by the network topology and latency. Our change explicitly randomizes this arbitrary choice, and therefore does not introduce new vulnerabilities." (Eyal & Sirer 2013)

  2. gmaxwell commented at 6:51 AM on November 5, 2013: contributor

    please see the extensive discussion on bitcoin-development and bitcointalk.

    What you're describing was known at least since 2010: https://bitcointalk.org/index.php?topic=2227.msg30083#msg30083

    The paper adds some extra assumptions about the attacker using a sybil attack to create an information/announcement advantage. Their proposed solution, however, actually creates incentives to delay— even absent a information/announcement advantage, which would result in very large miners (at sizes comparable to the largest pools) getting an excessive return.

  3. laanwj closed this on Mar 6, 2018

  4. Bushstar referenced this in commit 7677b55781 on Apr 8, 2020
  5. MarcoFalke locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-05-01 00:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me