For the 0.22 release we’ll want to start hardcoding Torv3 addresses instead of (or in addition to) Torv2.
The biggest challenge here is not how to hardcode them, although that will require a few minor script and code changes, but how to collect them. The release process is to get the addresses from DNS seeders, however these currently don’t support the addrv2 message nor Torv3 addresses in the first place. Nor do they really have a need to.
We would have non of this problems, if we had just encoded one v3 address in 3 or 4 ipv6 ADDR messages with some checksum and hash sort indexes btw.
But its not to late to use this method to hard encode them and have with some minor changes in the seeders software a DNS A/AAAA compatible way, If we don’t want to use SRV records, what is even a greater hassle,
On the other hand, since we seed with Tor only anyway with ADDR or ADDRv2 messages we learn form the first ipv4 or ipv6 DNS response when we try to resolve the seeders FQDN. We could just call them directly over a Tor onion address, its almost the same outcome. and we would stay in Tor and not use exit nodes, Some or one seeder must only update one of there nodes and learn from the ADDRv2 messages. That should build up fast if ppl use 0.21.and gossip ADDRv2 If we call then these v3 node directly on first virgin bootstrap, by just add them to the seeds list like we do with signet we stay in Tor and bootstrap with learned v3 addresses and leak even less, For storage in the code we would just add onion as the fqdn in the list that is only a minor change, since vseeds can hold even now fqdn like the seeders name.
Or we use the lightning method ref in #20175 to collect them.
We would have non of this problems, if we had just encoded one v3 address in 3 or 4 ipv6 ADDR messages with some checksum and hash sort indexes btw.
I don’t think there’s any guarantee for intermediate DNS servers to keep the results in the same order, or even not to remove results. But it doesn’t matter, it’s a red herring in the first place: there is no a reason to serve them over DNS. A node behind Tor can’t do the kind of DNS lookup that returns multiple results.
Despite that, the DNS seeder ’network exploration’ code could still collect them, in principle, for the purpose of making a list of hardcoded seeds and for statistics.
A node behind Tor can’t do the kind of DNS lookup that returns multiple results.
Exactly that’s my point all the time and its even hard to say if a rouge exit node give us even the first and only entry correct when we resolve the seeders names indirect over Tor to get a socket for our seeders name ( could be the first entry of the DNS call that the exit makes for himself or anything else ) or that the exit give us even the correct socket on return to a real bitcoin full node and because Tor only nodes would have and do bootstrap anyway over ADDR messages by the socket returned when we ask for seeder names or if we use the hard encoding, if we say -dnsseed=0, we could have just called seeders Tor addresses full nodes in Tor always directly and have let all other ip4/ip6 nodes give us dns A/AAAAA records as is learend from seeders or gossip and encoding v3 in AAAA and btw we would also be backwards compatible, if old node would run script and generate a connect or addnode list?
servers to keep the results in the same order
That’s why we would have needed some hashing and sortindex, redundancy to reassemble them correctly like a protocol that hides in a protocol. if we would have used the old A/AAAA aproach