The I2P netDB isn’t a single dumpable list like you’re suggesting. It’s a Kademlia DHT stored across rotating floodfill routers. Floodfills aren’t static — routers get promoted/demoted based on bandwidth, uptime, and capacity — so the view of the network is constantly shifting. A normal router only ever queries small slices of that DHT, meaning you never get the “whole picture” from one vantage point. That’s a deliberate design choice to make enumeration hard. On the traffic side, I2P isn’t just onion-style routing. It uses garlic routing, where multiple encrypted “cloves” (messages) are bundled together into one garlic message. This kills the simple “one in → one out” traffic correlation trick. Add to that the transports: NTCP2 is indistinguishable from normal TLS over TCP, and SSU2 is UDP with full encryption, padding, and replay protection. From a DPI standpoint, it looks like generic encrypted noise — there’s no clean handshake to match on like with old Tor circuits. As for blocking, I2P is decentralized. There are no directory authorities to censor, no fixed bridges to burn. Floodfills are chosen dynamically and constantly refreshed, and peers discover new ones automatically. The bigger the network gets, the harder it is to enumerate and blacklist enough routers to make a dent. Censors can try whack-a-mole, but the distribution effect scales against them: more peers in more ASNs across more countries means higher cost to block. So yes, you can suspect I2P traffic if you really try, but fingerprinting and wholesale blocking don’t scale — the protocol was designed specifically to make both correlation and censorship exponentially harder as adoption grows Details: https://www.youtube.com/watch?v=95hSAMEwrlM