p2p: Mitigate GETADDR fingerprinting by setting address timestamps to a fixed value #33498

1. 
   naiyoma commented at 3:21 pm on September 29, 2025: contributor

   This PR prevents a fingerprinting attack via GETADDR responses that allows correlating dual-homed nodes’ identities across different networks.

   When a node is connected to multiple networks (e.g., clearnet and Tor), it keeps separate ADDR response caches for each network. These are refreshed about once per day (randomized between 21 and 27 hours). See → https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L3519. An attacker can collect ADDR responses from supposedly different nodes and compare the timestamps. By looking at overlaps in responses, they can correlate Tor and clearnet identities — effectively linking them back to the same node.

   To prevent this, the PR removes timestamp-based correlation by assigning a fixed timestamp in the past (10.5 ± 2.5 days) to all entries within a given cache. Timestamps are uniform within each network-specific response, but differ across networks, preventing attackers from correlating identities via timestamp overlap.

   More details on this attack here: https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786

   This is joint work with @danielabrozzoni

2. DrahtBot added the label P2P on Sep 29, 2025
3. 
   DrahtBot commented at 3:21 pm on September 29, 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/33498.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   Concept ACK	jonatack, mzumsande, sipa

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

4. 
   jonatack commented at 4:38 pm on September 30, 2025: member

   Concept ACK on working on this. Good to see proposals like this and #33464.
5. in src/net.cpp:3559 in ece2916552 outdated

   3553@@ -3554,6 +3554,17 @@ std::vector<CAddress> CConnman::GetAddresses(CNode& requestor, size_t max_addres
   3554         // in terms of the freshness of the response.
   3555         cache_entry.m_cache_entry_expiration = current_time +
   3556             21h + FastRandomContext().randrange<std::chrono::microseconds>(6h);
   3557+
   3558+        const auto now{Now<NodeSeconds>()};
   3559+        const auto new_timestamp = now - std::chrono::minutes(8 * 60 * 24 + FastRandomContext().randrange(5 * 60 * 24));
   

   ---

   ---

   

   mzumsande commented at 5:30 pm on September 30, 2025:

   Since this is calculated on a level of minutes, it looks like it would give a range 10.5±2.5 days, not 10±2 days.

   ---

   

   naiyoma commented at 11:52 am on October 3, 2025:

   Yes, this is more precise, ive updated
6. 
   mzumsande commented at 5:45 pm on September 30, 2025: contributor

   Concept ACK

   The suggested solution reduces the precision of timestamps for the receiving party, but makes fingerprinting harder - seems like an acceptable trade-off to me.

   If there is an active node behind the address it won’t be Terrible for another ~20 days - until that happens, we could update it with a more accurate timestamp when we connect to it or receive the addr via gossip relay.

7. 
   sipa commented at 1:32 pm on October 1, 2025: member

   Concept ACK
8. net: set timestamps to a fixed time(10.5±2.5 days ago) for each cache

   Co-authored-by: Daniela Brozzoni <danielabrozzoni@protonmail.com>

   cec21bd2f7
9. test: check timestamp uniqueness per cache

   Co-authored-by: Daniela Brozzoni <danielabrozzoni@protonmail.com>

   28fe8ecae6
10. naiyoma force-pushed on Oct 3, 2025
11. naiyoma marked this as ready for review on Oct 8, 2025
12. 
    mzumsande commented at 4:11 pm on October 9, 2025: contributor

    I wonder if this could lead to addrs of nodes that have left the network never getting removed:

    The scenario is a well-connected node that is present in most other nodes’ addrmans, but that suddenly leaves the network or changes its IP.

    Currently what happens is that 1) It won’t self-advertise anymore and 2) after 30 days, the addr gets Terrible and won’t be part of GetAddr interactions between other nodes. So it won’t be relayed by anyone after that - It will stay a while in most nodes’ addrmans and eventually be replaced due to addrman collisions.

    With this PR, if an address older than 10 days (but not older than 30 days) is part of a GetAddr answer, the receiving peer will postdate its timestamp, giving it more time until it gets Terrible. There is a chaining effect, because the receiving peer will also relay it longer when it answers GetAddr requests itself, and so on. If this would happen frequently enough, the addr of the node that has left the network would always stay in the 10-30 day range and never cease to be relayed, and we’d be stuck with it forever - which would be problematic, because with enough time and node turnover, everyone’s addrman would get “full” and there would be no more room for actual new nodes. The crucial question is if GetAddr interactions happen frequently enough for this to be an important effect.

13. 
    naiyoma commented at 11:20 am on October 16, 2025: contributor

    With this PR, if an address older than 10 days (but not older than 30 days) is part of a GetAddr answer, the receiving peer will postdate its timestamp, giving it more time until it gets Terrible. There is a chaining effect, because the receiving peer will also relay it longer when it answers GetAddr requests itself, and so on. If this would happen frequently enough, the addr of the node that has left the network would always stay in the 10-30 day range and never cease to be relayed, and we’d be stuck with it forever - which would be problematic, because with enough time and node turnover, everyone’s addrman would get “full” and there would be no more room for actual new nodes.

    Thanks, this is insightful and likely to happen. I was initially thinking the other checks( m_last_success ) might still be useful to mark zombie addresses as terrible.

    But it’s unlikely that there would be enough attempted connections before the address is sent again.

    The crucial question is if GetAddr interactions happen frequently enough for this to be an important effect.

    I don’t have data on this yet - will grep and update soon

14. 
    danielabrozzoni commented at 1:21 pm on October 16, 2025: member

    Thank you Martin, I agree that the current solution has this issue.

    Our other approach would have run into the same problem. We had considered setting all timestamps to zero, but we didn’t implement it because we’re not sure if it’s compatible with btcd, as mentioned in the PR description. This approach has the same problem as the current one:

    • Suppose we have an address in our addrman with a timestamp of 29 days ago, and the corresponding node has already left the network
    • We send the address in a getaddr response with the timestamp set to 0
    • The receiving node interprets that as “5 days ago”

    So it ends up having the same problem: the address looks newer than it actually is, and it sticks around longer than it should, potentially forever.

    I’ve been thinking about an alternative solution, though I’m not sure if it makes sense. Perhaps an approach similar to the current one, but range-based, could work. Instead of setting every timestamp to 10 +- 2 days ago, we could adjust it based on how old the original timestamp is.

    As a rough idea (numbers are just placeholders for now), we could generate three random reference timestamps once: one around 25+-2 days ago, one around 15+-2 days ago, and one around 5+-2 days ago; then assign each address to one of these depending on how old its original timestamp is:

    • If older than 25 days → use the 25-day reference
    • If older than 15 days → use the 15-day reference
    • Otherwise → use the 5-day reference

    The exact numbers would need more thought. The fingerprinting issue would still exist: if two identities correspond to the same node, they would share the same initial timestamp and end up in the same range. Still, if we choose reasonable values, a large number of nodes might end up sending approximately the same timestamps.

15. naiyoma marked this as a draft on Oct 28, 2025
16. 
    naiyoma commented at 12:01 pm on October 28, 2025: contributor

    Moved back to draft, working on addressing -> #33498#pullrequestreview-3319680730

Contributors
naiyoma DrahtBot jonatack mzumsande sipa danielabrozzoni

Labels
P2P