This makes no sense now as there are hardly any

There are many nodes that have there onion v3 address linked to 8333 created in /etc/tor/torrc but probably won't tell and stay onlynet onion or don't enable service calls port 9051 and cant use the additional v3 support from 0.21 by auto creating onions anyway.

But since almost all old nodes versions can do connect and addnode with long v3 address since years, if thre Tor software is above Tor 0.3.2.2-alpha (October 2017 ), it might be useful to have a short list core approved list they could add manual to there old nodes,

And btw. why not add the Tor v3 addr from the known seeders ( if they have Tor nodes ) in the vseeds list, i.e. when the user selects onlynet=onion to make sure we don't seed by ADDR messages via Tor exit nodes and stay at least for virgin bootstrap in Tor, i somewhere posted a patch for chainparms.cpp but forgot where.
That way. nodes with 0.21 update would fast learn from the seeders ADDRv2 messages new v3 and stay in pure in Tor if they wish.
If u like i can dig for that?

diff --git a/src/chainparams.cpp b/src/chainparams.cpp
index ffd2076c9..4903e3bda 100644
--- a/src/chainparams.cpp
+++ b/src/chainparams.cpp
@@ -10,6 +10,7 @@
 #include <tinyformat.h>
 #include <util/system.h>
 #include <util/strencodings.h>
+#include <util/system.h>
 #include <versionbitsinfo.h>
 
 #include <assert.h>
@@ -113,6 +114,7 @@ public:
         // This is fine at runtime as we'll fall back to using them as an addrfetch if they don't support the
         // service bits we want, but we should get them updated to support all service bits wanted by any
         // release ASAP to avoid it where possible.
+        if (gArgs.GetArg("-onlynet", "") != "onion") {
         vSeeds.emplace_back("seed.bitcoin.sipa.be"); // Pieter Wuille, only supports x1, x5, x9, and xd
         vSeeds.emplace_back("dnsseed.bluematt.me"); // Matt Corallo, only supports x9
         vSeeds.emplace_back("dnsseed.bitcoin.dashjr.org"); // Luke Dashjr
@@ -122,6 +124,11 @@ public:
         vSeeds.emplace_back("seed.bitcoin.sprovoost.nl"); // Sjors Provoost
         vSeeds.emplace_back("dnsseed.emzy.de"); // Stephan Oeste
         vSeeds.emplace_back("seed.bitcoin.wiz.biz"); // Jason Maurice
+        };
+
+        if (gArgs.GetArg("-onlynet", "") == "onion") {
+        vSeeds.emplace_back("seedersv3onionaddressasdasdasdasdad.onion:8333"); // Add seeder onion v3 address
+       // since we can not seed over Tor UDP DNS and call anyway the first node from the return +       // the exit socket  the exit Tor node give us for the FQDN of normal seeders, so why not call    
+      //if onlynet=onion the Tor seeder node and gossip from ADDRv2 or ADDR,
+        }
 
         base58Prefixes[PUBKEY_ADDRESS] = std::vector<unsigned char>(1,0);
         base58Prefixes[SCRIPT_ADDRESS] = std::vector<unsigned char>(1,5);

concept ptACK
Tested only the Tor nodes and so far all on this new list encoded and decoded at boostrap and where except two reachable.

Tyi, those two on the list

4vorvtoyegh4zbvr.onion 8333
h6a32n4blbwwyn4d.onion 8333

i was unable to reach.

@Saibato Thanks for testing! Yes, I'd assume a part of them will be unreachable at any single time, I'm surprised the other 510 were connectable.

I'm surprised the other 510 were connectable

Me 2 , i did run the test twice, at first thought also impossible, but that was the case with a ten second delay between next address connect in the list.
But its v2 so there could be nodes doubles we wont be aware with the easy connect 8333 check i did.

Btw. a big improvement compared to the 3 working fixed that we only have now in 0.20

The changes look fine. I'm now running the instructions in contrib/seeds/README.md to see what I get. Edit: just saw the review tips in the PR description.

  IPv4   IPv6  Onion Pass                                               
427708  59843   8114 Initial
427708  59843   8114 Skip entries with invalid address
427708  59843   8114 After removing duplicates
427707  59843   8114 Skip entries from suspicious hosts
124199  52104   8001 Enforce minimal number of blocks
122607  51619   7794 Require service bit 1
  4769   1456   3830 Require minimum uptime
  4180   1126   3762 Require a known and recent user agent
  4089   1103   3762 Filter out hosts with multiple bitcoin ports
   512    143    512 Look up ASNs and limit results per ASN and per net

Ran makeseeds.py a second time to see the variance.

  IPv4   IPv6  Onion Pass                                               
427693  59849   8131 Initial
427693  59849   8131 Skip entries with invalid address
427693  59849   8131 After removing duplicates
427692  59849   8131 Skip entries from suspicious hosts
124185  52110   8018 Enforce minimal number of blocks
122597  51627   7810 Require service bit 1
  4752   1456   3842 Require minimum uptime
  4165   1126   3774 Require a known and recent user agent
  4076   1103   3774 Filter out hosts with multiple bitcoin ports
   512    147    512 Look up ASNs and limit results per ASN and per net

I confirm that running python3 generate-seeds.py . > ../../src/chainparamsseeds.h locally generates identical result.

Re-downloading the seeds and running python3 makeseeds.py < seeds_main.txt > nodes_main.txt changes nodes_main.txt about 12% (nodes_main.txt is 1167 lines and that command removed 137 lines and added 140).

Maybe as a future improvement we may devise some deterministic way to generate the seeds, so that everybody can generate seeds.txt and confirm http://bitcoin.sipa.be/seeds.txt.gz is not compromised. Or at least that there is a significant overlap between that file from bitcoin.sipa.be and a locally generated.

I confirm that running python3 generate-seeds.py . > ../../src/chainparamsseeds.h locally generates identical result.

@jonatack @vasild Thanks for checking !

Maybe as a future improvement we may devise some deterministic way to generate the seeds, so that everybody can generate seeds.txt and confirm http://bitcoin.sipa.be/seeds.txt.gz is not compromised. Or at least that there is a significant overlap between that file from bitcoin.sipa.be and a locally generated.

Yes, maybe.
Given the same seeds.txt.gz it should be deterministic already. Well, I guess the ASN mapping could change…
I could upload mine somewhere but I don't think it would prove anything. The thing is that the seeds.txt.gz on the server changes continuously, and there is no way to prove that mine was ever the current state there and hasn't been tampered with.

The topic of improvements to the seed generation comes up every time just before the release and then dies down immediately after it. I'm happy for someone to put effort in this though. See also #17020 which ahs quite the TODO list alrady 😄