rfc: only relay transactions to v2 encrypted peers #32373

issue Sjors openend this issue on April 29, 2025
  1. Sjors commented at 9:40 am on April 29, 2025: member

    Unless we don’t have any.

    One of the goals of p2p traffic encryption was to make it impossible for passive observers to figure out where a transaction originates. However as long as there’s enough unencrypted connections remaining, that doesn’t seem very effective.

    Assuming v2 transport adoption has reached an acceptable level, it may be a good time to start preferring it more strongly.

    Specifically I would suggest that we only relay transactions to v2 peers.

    If a v1 peer asks for a transaction, we should probably just give it to them. I suspect it’s break of backward compatibility if we don’t?

    We probably also want to continue receiving transactions from such peers, so we can’t just pretend to be blocksonly.

  2. Sjors commented at 9:50 am on April 29, 2025: member

    Related, but more radical: #29618

    There’s also #29415, but that’s limited in scope to our own transactions and relies on Tor / I2P.

  3. mzumsande commented at 2:42 pm on April 29, 2025: contributor

    Related, but more radical: #29618

    This proposal sounds more radical to me, assuming it’s meant to be the default and not optional like #29618. Once >90% of all nodes would implement it, v1 nodes wouldn’t percolate the network graph anymore, and the remaining v1 nodes (bitcoin core and alternative implementations) would become second-class citizens that wouldn’t see most transactions anymore before they are included in a block.

    Another aspect is that this does not help against the strategy of just connecting to all reachable nodes to find out the origin of transaction (the attacker would just use v2 for these connections).

  4. Sjors commented at 3:09 pm on April 29, 2025: member

    Indeed this change would be less radical than a default-off #29618. I meant in reference to a default-on version of that.

    the remaining v1 nodes (bitcoin core and alternative implementations) would become second-class citizens

    At some point https become non-optional too. But I don’t know when the right time is, probably not yet.

    does not help against the strategy of just connecting to all reachable nodes

    v2 transport doesn’t project against active attackers, only passive ones. That still seems like an improvement in theory, but maybe not in practice as long as active attacks are too easy.

  5. willcl-ark added the label Brainstorming on Apr 30, 2025
  6. willcl-ark added the label P2P on Apr 30, 2025
  7. willcl-ark added the label Needs Conceptual Review on Apr 30, 2025
  8. vasild commented at 1:37 pm on May 8, 2025: contributor

    I agree with @mzumsande above, also:

    If a node has even a single v2 connection that already makes it nearly impossible for a passive spying ISP to conclude it is the origin of a transaction, no?

    Lets assume a node has only v1 connections, then the ISP can observe all transactions going to it and all transactions going out of it. As soon as a transaction is seen going out that did not come in, a conclusion can be made that it originated from the node.

    However, if there are v2 connections, even just a single one, then the spy has no way to know. If they see an outgoing transaction for the first time, they cannot know whether the node is the origin or whether the transaction came from outside via the v2 connection and the node is just relaying it.


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: 2025-05-30 03:12 UTC

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