From: Sjors Provoost <sjors@sprovoost•nl>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
"Wladimir J. van der Laan" <laanwj@gmail•com>
Subject: Re: [bitcoin-dev] BIP proposal - addrv2 message
Date: Wed, 6 Mar 2019 10:05:09 +0100 [thread overview]
Message-ID: <00F86707-27B3-4153-8944-F71B4EF8AE95@sprovoost.nl> (raw)
In-Reply-To: <20190218075632.byec6ka7cat3rbiz@aurora.visucore.com>
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
prev parent reply other threads:[~2019-03-06 9:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 7:56 Wladimir J. van der Laan
2019-03-06 3:02 ` Gregory Maxwell
2019-03-06 9:05 ` Sjors Provoost [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00F86707-27B3-4153-8944-F71B4EF8AE95@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=laanwj@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox