the 2 block relay connections don't seem to be providing any value #22370

issue rebroad opened this issue on June 29, 2021
  1. rebroad commented at 12:10 PM on June 29, 2021: contributor

    In all my time running the code where 2 block relays are allocated, I have never seen them receiving any blocks - it's always the "full relay" nodes that are receiving the blocks.

    Perhaps I am misunderstanding the purpose of these 2 connections - but so far I am seeing no benefit in them - my understanding was that they were in some way more likely to be ready to receive a block than the "full delay" nodes, but this is not what happens from several weeks of observation.

  2. rebroad added the label Bug on Jun 29, 2021
  3. jonatack commented at 1:28 PM on June 29, 2021: member

    In all my time running the code where 2 block relays are allocated, I have never seen them receiving any blocks - it's always the "full relay" nodes that are receiving the blocks.

    I run watch -t ./src/bitcoin-cli -netinfo 4 for a continuous peer connections dashboard on my nodes, and the outbound-block-relay connections commonly provide blocks (and are correspondingly selected by my node as BIP152 high bandwidth peers).

    As for their purpose:

    src/net.h

        /**
         * We use block-relay-only connections to help prevent against partition
         * attacks. By not relaying transactions or addresses, these connections
         * are harder to detect by a third party, thus helping obfuscate the
         * network topology. We automatically attempt to open
         * MAX_BLOCK_RELAY_ONLY_ANCHORS using addresses from our anchors.dat. Then
         * addresses from our AddrMan if MAX_BLOCK_RELAY_ONLY_CONNECTIONS
         * isn't reached yet.
         */
        BLOCK_RELAY,
    

    https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Design-Philosophy is also a good resource, among others.

  4. MarcoFalke commented at 1:29 PM on June 29, 2021: member

    You can generally find more information in the pull request that added the code or in the code itself (comments).

    The goal of block-relay-only connections is not to "beat" the other connections when it comes to providing blocks. The goal is to harden the p2p network against attacks that exploit the p2p topology.

  5. MarcoFalke closed this on Jun 29, 2021

  6. rebroad commented at 3:39 PM on June 29, 2021: contributor

    what does "harder to detect by a third party" mean? detect what? the existence of the node? the connections to the node? If they are hard to detect then how does the average node find them?

  7. sipa commented at 6:36 PM on June 29, 2021: member

    Block-relay only connections provide two advantages over normal connections:

    • They have far lower bandwidth overhead, while still providing partition protection. This means we can create more of them without worrying about resources costs of the node. Or in other words, while 8 full + 2 block-only connections is weaker in terms of relay power than 10 full connections, it has similar partition resistance as 10 full connections, while only costing resources barely higher than 8 connections in total.
    • They don't relay IP addresses or transactions, both of which have been used in various academically described attacks that use these to infer the network topology graph. If part of the graph is harder to know by attackers, that indirectly makes partition attacks harder.

    In short: it's entirely expected that absent a partitioning attack, these connections don't do much.

    And to answer your question: it's not these nodes that are hard to detect - they're just normal nodes chosen at random like others - it's the presence of the connection that's hard to find.

  8. fanquake locked this on Jun 30, 2021
  9. fanquake removed the label Bug on Jun 30, 2021
  10. fanquake added the label Questions and Help on Jun 30, 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-04-22 18:14 UTC

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