doc: document fingerprinting risk when operating node on multiple networks #33750

1. 
   da1sychain commented at 9:55 pm on October 30, 2025: contributor

   Operating a Bitcoin node across multiple networks poses some fingerprinting risk. [0] Currently, this is not clear from the documentation and may be causing direct harm to users who are unaware of this.

   The included documentation change indicates this risk factor but also notes that operating a node across multiple networks does provide an important benefit (increases the cost of eclipse and partitioning attacks) and is thus not discouraged outright.

   The i2p documentation did not include a privacy recommendations section, so that is added as well.

   [0] https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786

2. DrahtBot added the label Docs on Oct 30, 2025
3. 
   DrahtBot commented at 9:55 pm on October 30, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33750.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	danielabrozzoni, rkrux, mzumsande, glozow
   Concept ACK	jonatack

   If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

4. Add eclipse, partitioning, and fingerprinting note in tor.md

   Minor spelling correction in privacy recommendations section

   19a6a3e75e
5. da1sychain force-pushed on Oct 30, 2025
6. da1sychain force-pushed on Oct 30, 2025
7. 
   jonatack commented at 10:27 pm on October 30, 2025: member

   See #33498.
8. in doc/tor.md:242 in 19a6a3e75e outdated

   237@@ -238,3 +238,9 @@ for normal IPv4/IPv6 communication, use:
   238   Otherwise it is trivial to link them, which may reduce privacy. Onion
   239   services created automatically (as in section 2) always have only one port
   240   open.
   241+- Operating a node that listens on multiple networks (e.g. IPv4 and Tor) can increase
   242+  the cost and complexity of eclipse and partition attacks. However, under certain
   

   ---

   ---

   

   mzumsande commented at 1:50 pm on October 31, 2025:

   maybe add something like “… and therefore helps strengthen the network” to stress that it’s also common to be a bridge node for altruistic reasons, even if the node operator isn’t particularly concerned about attacks on their own node.

   ---

   

   da1sychain commented at 7:46 pm on October 31, 2025:

   Thank you, good idea. Added some clarifying language to that sentence.
9. 
   mzumsande commented at 2:11 pm on October 31, 2025: contributor

   Concept ACK

   I think that fingerprinting attacks are easy enough (and some, such as #33498, are hard to fix) that this warning is justified. Fingerprinting methods have never been researched systematically as far as I know, so I’m sure there are various unknown ones besides the ones publicly and privately known. Newly found fingerprinting methods aren’t classified as CVEs but reported and fixed openly. So this is just a reflection of the status quo.

   If we manage to make progress and, in a few years, are confident that fingerprinting is really hard / impossible, that would be great and we could remove this again, but I don’t think we are even remotely close to that state yet.

10. in doc/tor.md:246 in 19a6a3e75e outdated

    237@@ -238,3 +238,9 @@ for normal IPv4/IPv6 communication, use:
    238   Otherwise it is trivial to link them, which may reduce privacy. Onion
    239   services created automatically (as in section 2) always have only one port
    240   open.
    241+- Operating a node that listens on multiple networks (e.g. IPv4 and Tor) can increase
    242+  the cost and complexity of eclipse and partition attacks. However, under certain
    243+  conditions, an adversary that can connect to your node on multiple networks may be
    244+  able to correlate those identities by observing shared runtime characteristics. It
    245+  is not recommended to expose your node over multiple networks if you require
    246+  unlinkability across those identities.   
    

    ---

    ---

    

    mzumsande commented at 6:54 pm on October 31, 2025:

    linter complains about trailing whitespace (in both commits)
11. da1sychain force-pushed on Oct 31, 2025
12. da1sychain force-pushed on Oct 31, 2025
13. Add eclipse, partitioning, and fingerprinting note to i2p.md

    Also introduced a Privacy Recommendations section to docs.

    e346ecae83
14. da1sychain force-pushed on Oct 31, 2025
15. 
    darosior commented at 8:04 pm on October 31, 2025: member

    See #33498.

    This is only one such vector. It’s good to have a warning until we can be reasonably confident that it’s not trivially possible to link two different network addresses of a node. I am also skeptical we could ever reach this level of confidence.

16. in doc/tor.md:241 in e346ecae83

    237@@ -238,3 +238,10 @@ for normal IPv4/IPv6 communication, use:
    238   Otherwise it is trivial to link them, which may reduce privacy. Onion
    239   services created automatically (as in section 2) always have only one port
    240   open.
    241+- Operating a node that listens on multiple networks (e.g. IPv4 and Tor) can help
    

    ---

    ---

    

    jonatack commented at 9:07 pm on October 31, 2025:

    Idem.

    0- Operating a node that listens on multiple networks (e.g., Tor and I2P) can help
    

17. in doc/i2p.md:172 in e346ecae83

    165@@ -166,3 +166,13 @@ In most cases, the default router settings should work fine.
    166 
    167 Please see the "General Guidance for Developers" section in https://geti2p.net/en/docs/api/samv3
    168 if you are developing a downstream application that may be bundling I2P with Bitcoin.
    169+
    170+## Privacy recommendations
    171+
    172+- Operating a node that listens on multiple networks (e.g. IPv4 and I2P) can help
    

    ---

    ---

    

    jonatack commented at 9:08 pm on October 31, 2025:

    While the study linked to in the OP described IPv4 and Tor, I suspect the most frequent multiple network pairing would be Tor and I2P, as privacy network users might opt to avoid clearnet (say, the kind of node operator that pre-I2P may have been running over Tor only. I believe some node-in-a-package software encourage running these two with one-click toggles.)

    0- Operating a node that listens on multiple networks (e.g., I2P and Tor) can help
    

    ---

    

    da1sychain commented at 10:17 pm on October 31, 2025:

    This combination, IMO, poses less risk to the privacy-concerned individual as they are exposing their node over two privacy networks. In fact I think the risk in this configuration would be lean more towards isolation / partition.

    ---

    

    jonatack commented at 3:51 pm on November 11, 2025:

    This combination, IMO, poses less risk to the privacy-concerned individual as they are exposing their node over two privacy networks.

    Perhaps clarify that in the documentation, as those that do run over both Tor and I2P could conclude that they risk being fingerprinted in the same way as described here.

    I could be wrong, but I don’t see who would listen on both clearnet and Tor (or I2P) if they are concerned about privacy. ISTM those who do that are willingly providing a service to the network or gathering data/doing research.

    Perhaps also provide explicit workarounds, rather than hinting at them, like turning off listening, or running two separate nodes each on one network that connect manually to each other.

    ---

    

    glozow commented at 2:37 pm on November 12, 2025:

    I could be wrong, but I don’t see who would listen on both clearnet and Tor (or I2P) if they are concerned about privacy.

    Perhaps not everybody understands it as well as you do. The purpose of this PR is to more explicitly inform people who aren’t fully aware of the risks.

    ---

    

    jonatack commented at 2:58 pm on November 12, 2025:

    The purpose of this PR is to more explicitly inform people

    That is why I suggest providing actionable steps in this documentation for those who are concerned.

    ---

    

    jonatack commented at 3:00 pm on November 12, 2025:

    Perhaps clarify that in the documentation, as those that do run over both Tor and I2P could conclude that they risk being fingerprinted in the same way as described here.

    Would be good to address this as well.

18. 
    jonatack commented at 9:13 pm on October 31, 2025: member

    Concept ACK
19. 
    danielabrozzoni commented at 7:33 am on November 3, 2025: member

    ACK e346ecae830e10310979e5f64de63e043a383ff1

    I really like how it’s written, it’s really fair and balanced, without sounding scary. Thanks for working on this! :)

    Just a small nit, you included the suggestions from #33750 (review) and #33750 (review) in the second commit (e346ecae830e10310979e5f64de63e043a383ff1). This makes the first commit modify only tor.md, while the second one changes both tor.md and i2p.md. You might want to separate them so the first commit updates tor.md and the second one updates i2p.md.

20. DrahtBot requested review from mzumsande on Nov 3, 2025
21. DrahtBot requested review from jonatack on Nov 3, 2025
22. da1sychain force-pushed on Nov 4, 2025
23. 
    da1sychain commented at 8:47 pm on November 4, 2025: contributor

    Good catch and thank you for the review @danielabrozzoni!! I’ll go ahead and fix that.
24. rkrux approved
25. 
    rkrux commented at 12:16 pm on November 11, 2025: contributor

    crACK e346ecae830e10310979e5f64de63e043a383ff1

    This advisory note is helpful.

26. 
    mzumsande commented at 2:40 pm on November 11, 2025: contributor

    ACK https://github.com/bitcoin/bitcoin/commit/e346ecae830e10310979e5f64de63e043a383ff1

    nit: Commit separation is still not clean (second commit still touches tor.md).

27. in doc/tor.md:247 in e346ecae83

    245+  the cost and complexity of launching eclipse and partition attacks. However, under certain
    246   conditions, an adversary that can connect to your node on multiple networks may be
    247   able to correlate those identities by observing shared runtime characteristics. It
    248   is not recommended to expose your node over multiple networks if you require
    249-  unlinkability across those identities.   
    250+  unlinkability across those identities.
    

    ---

    ---

    

    glozow commented at 2:35 pm on November 12, 2025:

    In the future, please squash your fixes onto the commit itself, otherwise there is an intermediate state that doesn’t pass CI.
28. 
    glozow commented at 2:38 pm on November 12, 2025: member

    lgtm ACK e346ecae830e10310979e5f64de63e043a383ff1

    Remaining comments look optional, merging

29. glozow merged this on Nov 12, 2025
30. glozow closed this on Nov 12, 2025

    ---

31. TheCharlatan referenced this in commit 7f93626ea0 on Nov 12, 2025

Contributors
da1sychain DrahtBot jonatack mzumsande darosior glozow danielabrozzoni rkrux

Review Requested
jonatack

Labels
Docs