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

[naiyoma]

TLDR: 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
This is an example of a dual-homed node’s addrman response, with separate caches:

IPv4 response:

{102.130.242.11:8333 : 1741100851}
{119.17.151.161:8333 : 1739825443}
{ubeirqalc4vj54baszpatvctpohn62hzj7vfnbncy6upa6vywvgewrad.onion:8333 : 1739825443}

Tor response:

{102.130.242.11:8333 : 1741100851}
{94.23.167.176:8333 : 1740895525}
{ubeirqalc4vj54baszpatvctpohn62hzj7vfnbncy6upa6vywvgewrad.onion:8333 : 1739825443}

Currently, there's a fingerprinting attack that exploits responses to GETADDR messages. An attacker can collect 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.
More details on this attack here: https://delvingbitcoin.org/t/fingerprinting-nodes-via-addr-requests/1786

This PR mitigates the attack by setting the timestamps in different caches to a fixed value in the past (10.5 ± 2.5 days), preventing correlation through timestamps.
After the change, timestamps in each cache are now uniform, but differ between caches:

IPv4 response:

{102.130.242.11:8333 : 1757964675}
{119.17.151.161:8333 : 1757964675}
{ubeirqalc4vj54baszpatvctpohn62hzj7vfnbncy6upa6vywvgewrad.onion:8333 : 1757964675}

Tor response:

{102.130.242.11:8333 : 1757878277}
{119.17.151.161:8333 : 1757878277}
{ubeirqalc4vj54baszpatvctpohn62hzj7vfnbncy6upa6vywvgewrad.onion:8333 : 1757878277}

We initially considered setting the timestamps to 0, since they would eventually be updated and saved. However, this isn’t compatible with btcd (see details here → btcsuite/btcd#2411 ).
This is still a work in progress — we’re continuing to test and are open to trying other solutions as well.

This is joint work with @danielabrozzoni

[DrahtBot]

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.

[jonatack]

Concept ACK on working on this. Good to see proposals like this and #33464.

[mzumsande]

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.

[sipa]

Concept ACK