[brainstorm] DoS protection for blocks #9530

issue sipa openend this issue on January 12, 2017
  1. sipa commented at 5:02 pm on January 12, 2017: member

    (summary of a discussion with @sdaftuar and @morcos)

    As shown by the discussion of #9375, one issue is the expectation that (existing) peers have that block messages are never consensus-invalid. This complicates logic significantly, as much of the faster block relay relies on not knowing this ahead of time.

    BIP152 essentially introduces an exception. This leads to the question: is this assumption necessary at all?

    I don’t think it is. Block validation is expensive, but producing an (invalid) block is very expensive. At the current difficulty, producing a PoW-valid block with state of the art mining hardware requires over 40000 kWh of energy. Using the difficulty at the last checkpoint (which we want to get rid, but it would be replaced by another mechanism for preventing low-difficulty header bloat), it is still 730 kWh. And that’s just for doing a single attack that causes ~seconds of CPU work for network nodes - a persistent one would be prohibitive. Another way of looking at it is that our current protection against this (DoS banning) is likely much cheaper to bypass (get extra IP addresses) than what it already costs to produce invalid blocks.

    So I’d like to propose that for blocks, we only DoS ban/disconnect for headers with invalid PoW or building on top of a header with invalid PoW. Specifically, a header building on top of an invalid block (with valid header) would be permitted.

    Possible issues that may arise and need separate solutions:

    • Header spamming (which is currently prevented by checkpoints, but could be replaced with a different rule - out of scope here).
    • Detecting whether all our connections are to nodes that are on different networks. This could be improved by just having rotating connections (is there no issue for this already?) or by marking peers which have a pindexLastCommonBlock that over long periods of time remains forked off from out best chain.
  2. TheBlueMatt commented at 9:46 pm on January 12, 2017: member
    Someone should probably add to the “Projects” list “Redo DoS scoring entirely” - generally I think most of us have agreed that we should throw out the DoS scoring shit and have some similar logic to the connection-replacement-on-new-peers logic, where we score peers based on things like “you’re on a different chain that diverged from me long ago”, “you keep sending me invalid crap”, etc.
  3. sipa commented at 9:57 pm on January 12, 2017: member

    I agree with those things as well, but I think they’re orthogonal (depenalizing invalid blocks with valid PoW can happen within the current DoS-scoring system, and keeping the existing score-100 misbehavior as instant bans in a no-DoS-score world).

    If you want to see them as part of the same effort, there are more things to take into account:

    • Tracking of resource usage per peer, allowing us to disconnect/deprioritize some in favor of others, without introducing a partitioning risk.
    • Introducing mechanisms for peers to tell other peers what rules they demand on transactions (which don’t benefit from the PoW protection blocks have, but still sometimes need new filtering to prevent excessive resource usage that is fixed by new softforks).
    • Integration with the incoming connection rotation to give better peers a chance while we’re already ful.
  4. fanquake added the label Brainstorming on Jan 12, 2017
  5. gmaxwell commented at 2:39 pm on January 15, 2017: contributor
    If the anti-partitioning works another way, then I don’t see a reason to ban on bad blocks.
  6. MarcoFalke added the label P2P on Mar 29, 2022

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: 2024-07-03 10:13 UTC

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