Is your feature request related to a problem? Please describe.
DNS seeding for Tor V3 Edwards curve nodes is not possible in the current A/AAAA design.
Describe the solution you’d like
Support for Tor v3 seeding: By creating a BIP that outlines how that can be done.
Until we have that: Add at least some fixed v3 node addresses in the vSeeds list.
DNS seeding for Tor V3 nodes is not possible in the current A/AAAA design. When v2 fades out seeders are unable to hand over learned known V3 onions encoded in there DNS A/AAAA answer records.
Not that enable DNS seeding while using Tor is a good privacy idea anyway, but since some users are behind chains of NAT’s and just like or must bootstrap over Tor, we should support that.
With the next release, users will be reachable by V3 onions the node created and gossip them but be unable to get also those onion V3 seeds by the build in seeders or there own DNS Tor v2/ipv4/6 seeders in the usual fashion on a clean bootstrap.
So to mitigate against fragmentation, at least we should add some build in v3 node addresses i.e. from the known seeder nodes. So nodes have a chance to stay solely in Tor and v3 and are not forced to leak.
Or/and think about building for and using something like the lightning mechanism to support also seeding like we used to now also for Tor v3 onions. https://github.com/lightningnetwork/lightning-rfc/blob/master/10-dns-bootstrap.md
general caveat of long v3 onion names is that we can no longer bootstarp in out of ip4/ip6 by use of A and AAAA records that fit the now long onion address, but might be forced to support DNS SRV calls for the long names but SRV DNS calls are not supported by Tor and the socks5 proxy. So the task is that we must find a way to bootstrap in a private maner before Tor v2 fades out.
Describe alternatives you’ve considered
Until we have that: Add at least some fixed v3 node addresses in the vSeeds list.
Additional context https://github.com/lightningnetwork/lightning-rfc/blob/master/10-dns-bootstrap.md
