Question about `ADDR`/`ADDRv2` timestamp handling

[danielabrozzoni]

Hi, @naiyoma and I are currently researching how ADDR can be changed to prevent fingerprinting nodes through timestamps. We have a few ideas for possible changes, and we're reviewing alternate clients to make sure we don't accidentally break compatibility.

(For more context, here is the discussion on Delving Bitcoin: Fingerprinting nodes via addr requests)

The idea we are currently considering is: in every ADDR/ADDRV2 message sent in response to GETADDR, set every timestamp to 0.

This is compatible with Bitcoin Core, because when receiving a timestamp <= 100000000s, the node sets it to five days ago. This means these received addresses would be stored in addrman with a timestamp of five days ago, and the isTerrible logic would still work as intended.

I am reviewing btcd and I don't think the proposed solution would work with btcd, so we may need to find a different one. But before that, I want to make sure I correctly understand the btcd code.

This is my understanding of the btcd behavior:

• ADDR/ADDRv2 messages are handled in server.go in OnAddr and OnAddrV2.
• The timestamp is only checked to prevent storing values in the future. Unlike Bitcoin Core, there is no special handling for timestamp <= 100000000s.
• As a result, when btcd receives an ADDR with timestamp = 0, it inserts the address with timestamp = 0 into the address manager.

The btcd address manager works similarly to Bitcoin Core's, with an isBad check that marks an address as "bad" if its timestamp is older than 30 days. This would cause all such entries to be treated as bad right away.

Is my understanding correct, or am I missing something?
Thank you in advance :)