1. Reflected IP detection is cool, but I'm not sure whether it was intended to work with my case of double NAT.

The setup:
PC → Home LAN → NAT1 (on home router, but port forwarded via UPnP) → ISP LAN → NAT2 (Carrier-grade NAT) → Global Internet

Home LAN addressing is 192.168.10.0/24. ISP LAN addressing is 100.64.0.0/10 (dedicated CGNAT range). Then there's one of the public addresses from ISP-assigned AS, usually static for weeks. NAT2 also translates the port number.

I have noticed that many client addresses from ISP LAN appear as DHT nodes or even as peers on some popular torrents. It is generally desired because local peers might have extra fast speeds. However, their amount is so big (the client is reachable to everyone else from ISP NAT) that it often makes Tixati think that the public location is ISP LAN address (one assigned from 100.64.0.0/10) with configured & forwarded port instead of public address after ISP NAT with a real NAT'ed port. Those two locations are shown, and compete with each other.

Ports log shows that preferred location switches every 10-100 seconds. The ISP is a big one (city-wide), so it has a lot of torrent users. Interestingly enough, it seems that in the early morning and around noon, when the most users don't use their home computers, local peers rarely overpower the global peers.

I'm not sure how it affects the data that is sent to peers, but an address from 100.64.0.0/10 can only be secondary to the real public address and port.

2. DHT cleanup seems over-zealous or dependent on external factors.

At the moment, my DHT table seems a bit wretched:
https://files.catbox.moe/1i7vjr.PNG

That's using a client with hundreds of torrents and 15 parallel DHT lookups. If a client has less active torrents, the DHT table looks a tiny bit better, with 10 nodes in buckets from /5 to /11 or /12, and just 1-5 nodes in closer buckets. Resetting node ID, client port, and deleting dht2.dat produces the same result.

I thought it might be related to address flapping between ISP LAN and Internet ones, but it seems that even with stable correct address, DHT table does not grow.

Individual lookups still contact up to 200 nodes, and 9 times out of 10 produce 0-2 peers (probably bots), so the fake routing nodes still direct the client to the non-existing or fake peers, and prevent it from reaching a subset of closest nodes (closest ones that get the announce usually only match the first byte or two of the hash). Only the most popular torrents produce a hundred or so peers after a search. Local IP filters have been disabled deliberately.

3. There is no output for the list of automatically blocked DHT nodes to check for correctness or compare with other results.

I know that the filtering works, as I don't see the usual suspects in the lists, but what exactly is blocked? Have valid nodes been blocked for some reason?

4. Tixati does not automatically promote peers to DHT node candidates.

If bootstrap server is not available (captive portal might go nuts, or HTTP might get severely filtered, or server/hoster might be blocked), clean Tixati install does nothing with DHT until you add some online peers from some torrents to bootstrap settings. In other popular clients, it is enough to add known working torrent with a known working tracker (Ubuntu .iso) to get hundreds of peer addresses, as most of those are also valid DHT nodes.

Peers with which we successfully exchanged data are known good DHT candidates. They can even be preferred as more valid, and displace random ones when needed.