💡[new Pluggable Transports] proposal DHT

DHT has fewer traffic characteristics than Snowflake, and ISP operators don’t even know you are using TOR.
A large number of users use DHT

DHT

dht.libtorrent.org:25401
dht.transmissionbt.com:6881
router.bittorrent.com:6881
router.utorrent.com:6881
dht.aelitis.com:6881


other

Can you clarify how exactly DHT can be utilized to gain access to Tor? What components need to be implemented?

2 Likes

I think it would be similar to having a broker included in each proxy :grinning:

client → ← DHT → ← relay

client → ← DHT → ← quic:// → ← relay

client → ← DHT → ← snowflake → ← quic:// → ←
relay

This reminds me of ZeroNet.

Which brings up some questions:

Bittorrent transmission doesn’t use the QUIC protocol, making this transmission method extremely easy to detect (a client suddenly switches to using the QUIC protocol to communicate with previously connected nodes after initiating a DHT network connection). ZeroNet also does poorly in this regard (China hasn’t blocked 0Net only because there are few users, making it not worth the attention).

I think solving the problem of malicious nodes in the DHT network will be another challenge (ZeroNet once tried to implement a DHT network for 0Net, but ultimately failed to do so due to the inability to solve the problem of establishing trust between clients).

Tracker servers are not that reliable, and it’s easy for tracker servers to detect that it’s not a Bittorrent client. Maintaining trusted tracker servers would also make it easier for censors to block the entire network.