Re: [bitcoin-dev] BIP proposal - addrv2 message

[Sjors Provoost <sjors@sprovoost.nl>]

Concept ACK.

> ==Considerations==
> 
> (to be discussed)
> 
> * ''Client MAY store and gossip address formats that they do not know about'': does it ever make sense to gossip addresses outside a certain overlay network? Say, I2P addresses to Tor? I'm not sure. Especially for networks that have no exit nodes as there is no overlap with the globally routed internet at all.

What exactly do you mean by "do not know about"? It could mean:

1. A new Network ID was recently introduced which an older node doesn't about.

In that case the node won't even know the address length, so it can't parse the entry.

In fact it can't parse the entire address message if a single address has an unknown format. Maybe require a single address type per ADDR2 message?

2. The Network ID doesn't match the network the node received this message on

The node should probably be agnostic about where it received this information from.

3. The node currently doesn't support a Network ID

But what does that mean? No connection? An explicitly disabled setting? A missing dependency? The operating system doesn't support it?

I think "MAY" is the correct choice for storing for (2).

For (3) I think it makes sense for nodes to store information even if they're disconnected, but not if they have a setting disabled or no driver. Though that implementation detail doesn't seem relevant to the standard.


I don't think it's a good idea to gossip information you can't at least in theory verify, but we already do that with Tor V2. It's useful to gossip information about other networks to help e.g. IPv4 nodes bootstrap Tor connections. On the other hand, that could also help an attacker link them. We could recommend that with addrv2 the node should make sure gossip messages were received on the correct interface, but that may not be practical.

> * Lower precision of <code>time</code> field? seconds precision seems overkill, and can even be harmful, there have been attacks that exploited high precision timestamps for mapping the current network topology.
> 
> ** (gmaxwell) If you care about space time field could be reduced to 16 bits easily.  Turn it into a "time ago seen" quantized to 1 hour precision. (IIRC we quantize times to 2hrs regardless).

That seems like a good idea.

> * (gmaxwell) Optional (per-service) data could be useful for various things:
> [...]
> ** If we want optional flags. I guess the best thing would just be a byte to include the count of them, then a byte "type" for each one where the type also encodes if the payload is 0/8/16/32 bits. (using the two MSB of the type to encode the length).  And then bound the count of them so that the total is  still reasonably sized.

Adding more information seems useful, though also creates more topology mapping opportunities.

- Sjors