Fingerprinting nodes via addr requests

[Crypt-iQ]

@danielabrozzoni

One possible explanation for this behavior is that GETADDR caches for different interfaces are refreshed at different times. The refresh timing is randomized, and a cache is only updated when a GETADDR request is received. Since each cache acts as a “snapshot” of the node’s addrman at the moment it’s refreshed, differences in refresh time can lead to discrepancies between caches for different interfaces.

I think this may instead be due to the ability of nTime to be refreshed?

Timestamps are also used in gossip relay (a separate mechanism from GETADDR) of node announcements.

Oh, right.

I wonder if there would be major downsides if we’d just indiscriminately set the timestamp of each address from a GETADDR answer to a randomised but fixed value in the past (e.g. 10 +/- 2 days ago) when creating the cached response, not using our nTime information at all (with a different random value for each cache of course).

Is it possible that this would cause the address to become “terrible” quicker if it’s successively requested by GETADDRs across a path (i.e. B requests from C, A requests from B)?