I’m about to commit a patch that implements tunneling of the DHT traffic over TCP. The motivation is to make twister compatible with TOR (they do not support UDP, required by DHT).
So how this thing works?
The premise is that most of people will still be running twister outside TOR, thus with full internet connectivity including UDP. These nodes will behave as “DHT proxies” to nodes without UDP, relaying the traffic back and forward.
The TCP connection used is the same as the registration network, that is, the Bitcoin P2P protocol, now extended with DHT requests and replies commands.
Of course, some limits will be enforced, like maximum number of simultaneous DHT requests and total requests/second. If node misbehave it will be banned (Bitcoin closes connection).
Nodes requiring DHT proxy do not rely on any particular nodes for that service: they will randomly choose four connections to use for each DHT request they made. This should help to balance the load and also adds redundancy.
So far I have only tested it locally, so you might guess this is pretty much experimental.
Besides, I don’t think we are tor-ready yet: the DHT traffic used for profiles, avatars etc has been tunneled but not the internal DHT requests from libtorrent (ie. tracker requests).
But we are getting there…
Please merge this with libtorrent upstream. Its useful to allow peer discovery and sharing of censored media through Tor.
Not possible. The DHT is tunneled throught Bitcoin TCP connection.
This is a good start, but it would be better if it didn’t rely on non-tor clients. Twister could be 100% torified if DHT node was actually a Tor Hidden Service.
I really like the decentralized aspect of Twister, and am very impressed by the blockchain incentive, but I find the privacy claim on its homepage kind of absurd: “The IP address you use to access twister is not recorded on any server. Your online presence is not announced.” is simply false for Twister users today who aren’t using Tor.
If an attacker wants a list of IPs of people reading a certain thing, they can specifically position themself in the DHT so that their nodes are responsible for serving that thing. The newly-added Tor support in twister solves that problem for users using Tor.
It doesn’t solve the censorship problem though. Censorship-resistant DHTs are a very difficult problem which there is not yet a complete solution for as far as I know. Tor Hidden Services are censorable today, by attacking their DHT with the technique I described above. There is a hidden service redesign underway which will mitigate these problems, but not solve it completely.
I highly recommend that you get more involved with Tor, check out the hidden service DHT redesign plans, and consider making Twister require Tor (at least for full nodes; I expect if/when Twister takes off most users will use it via gateways).
I also recommend softening the privacy claims you’re making about Twister.
Thanks for your interesting feedback. Good food for thought.
You are not supposed to be able position yourself wherever you want in DHT because your node ID depends on your IP. Yes, I agree with you that currently this is very easy to overcome given twister’s small number of nodes (one just has to try a few of the random IDs he is allowed to use to position himself). The premise, of course, is based on a bigger network of nodes. The paper and FAQ also makes clear this is also not resistant against an attacker in possession of a wide range of IPs to use, such as a government.
Reading the whitepaper now… I’m confused. Are DHT nodes’ IDs just a hash of IP:port? That seems reverseable (48 bits) and also still gives someone with a single IP address a lot of freedom (in the 16-bit port number) to position themself as a node for a particular piece of content.
see http://www.bittorrent.org/beps/bep_0042.html