prevent 51% attacks as well miner hashing concentration #2345

issue fervent-dissent opened this issue on March 6, 2013
  1. fervent-dissent commented at 10:24 AM on March 6, 2013: none

    The bitcoin network could have built in and automated monitoring and prevention measures to prevent any group from controlling 51% of the network.

    My proposed solution is to divide network hash rate,or block generation submission rate, by unique miner ips over some interval to provide caps on accepting new proof of work units from the same ip address over short time intervals.

    The next level of security would be to prevent high frequency submissions from some kind of ip address cycling from sources with assigned ip address blocks.

    I thought of this mainly as an ipv4 measure, as I'm not sure how ipv6 can be used to help prevent 51% take overs.

    The affect of this is that disruptive technologies can no longer monopolize network hashing power when used from a few or single ip addresses, and indirectly miner payouts of blocks and transaction fees will be moderated during transitions to asic and other future technologies.

  2. gmaxwell commented at 10:39 AM on March 6, 2013: contributor

    What you're suggesting would not be effective: Anyone can get access to many IPs, Bitcoin has no central authority to certify blocks came from the IPs they're claimed to have come form. Nor is otherwise "moderating" actually a desirable thing. The system is self-regulating.

  3. hrobbins commented at 5:41 PM on March 13, 2013: none

    "The system is self-regulating" sounds like famous last words. Is there anything in this "self-regulating system" to stop someone from hacking the top mining pools and injecting code to take over the network?

    That said, tying things to IP is most certainly a useless effort. I might suggest alternatively some trust metric. eg. The more hashing power you contribute (the greater your ability to do damage proportional to the capacity of the network) the less you're trusted in relative terms, sort of a check and balance against majority rule. Another valuable trust metric might also be to trust individuals who have been generating reliable results the longest over individuals who have just joined the network. Still not a perfect solution, but might at least avoid the scenarios where a) an entity takes over a few of the leading mining pools, and b) the scenario where someone introduces more 10x improvements in mining ability, c) it may also stop cases like we've recently seen, where a bug was introduced into the newest version of the miner that created a conflicting block-chain.

  4. tobypinder commented at 10:33 PM on March 14, 2013: none

    These are interesting ideas but there are obvious (albeit nontrivial) countermeasures that can be taken to thwart them. Unless a perfect solution is found (and that'd be pretty unlikely to even exist in my humble opinion given the anonymity inherent) any "51% detection system" merely risks causing a false positive.

    People ultimately vote with their hardware: it's a somewhat brute force but elegant solution (much the same as many of bitcoins' innovative technologies like the public ledger and mining itself). The suggested solutions all introduce levels of global "trust" via some arbitrary metric that could unfortunately be gamed.

  5. gmaxwell commented at 12:51 AM on March 15, 2013: contributor

    @hrobbins I'm happy you are interested but your response is a handwave— "The more hashing power you contribute" ... how is you defined? "less you're trusted" ... trusted in what way?

    The self-regulating comment was wrt fervent-dissent's "moderated during transitions"— the system has a feed-forward control loop to keep the block rate controlled during such transitions and doesn't appear to need any additional help (even if fervent-dissent had specified some way that it actually could be helped). It wasn't a comment with respect to "51%"— the inability to handle >50%+1 byzantine faults is unfortunate, but appears to be fundamental. @tobypinder "albeit nontrivial" I've seen nothing suggested here which was even that useful alas.

  6. hrobbins commented at 4:58 AM on March 15, 2013: none

    @gmaxwell wrt "The system is self-regulating" I misunderstood. Also thought it would be clear "you" would be an address that mined bitcoins would be awarded to. "Trusted" being in terms of deciding consensus on the block chain, taking the chain with the greatest trust behind it that factored in risk from unknown and high powered contributors, rather than the greatest difficulty (hashing power). @tobypinder I agree something more rigorous would be needed. "A perfect solution" is not. There's something to be said for defense in depth. The more difficult you can make it for an attacker the better, all you need is to insure the cost isn't going to be worth the benefit. Right now, it's not, if/when Bitcoin starts to threaten governments, or have a significant impact on the financial system in general, it may.

  7. hrobbins commented at 6:34 PM on March 15, 2013: none

    Is there any system in place that currently monitors for attacks on the network? (Other than double spending?) Seems like the obvious first step.

  8. gmaxwell commented at 6:43 PM on March 15, 2013: contributor

    @hrobbins What attack are you asking about and I'll let you know if I know of something that monitors for it?

  9. hrobbins commented at 7:23 PM on March 15, 2013: none

    @gmaxwell Specifically thinking about the >50% attack, the "Cancer Nodes" attack, or general misbehavior of the network like the 0.7/0.8 fork which seemed to catch people off-guard.

  10. laanwj closed this on Oct 25, 2013

  11. bitcoin 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-20 06:55 UTC