From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 6 Mar 2019 10:05:09 +0100
References: <20190218075632.byec6ka7cat3rbiz@aurora.visucore.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	"Wladimir J. van der Laan" <laanwj@gmail.com>
In-Reply-To: <20190218075632.byec6ka7cat3rbiz@aurora.visucore.com>
Message-Id: <00F86707-27B3-4153-8944-F71B4EF8AE95@sprovoost.nl>
Subject: Re: [bitcoin-dev] BIP proposal - addrv2 message
Precedence: list

Concept ACK.

> =3D=3DConsiderations=3D=3D
>=20
> (to be discussed)
>=20
> * ''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.
>=20
> ** (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