Create a gist now

Instantly share code, notes, and snippets.

Putting the "Tor" back in Torrent

Putting the "Tor" back in Torrent

How a Popcorn Time fork patch could incentivize people to run thousands of new Tor relays

This is a follow-up to this discussion: Can NAT traversal be Tor's killer feature?

If torrents are P2P's killer application, and NAT traversal/"static IP" are Tor's (via hidden services), putting them together could prove to be the best incentivization scheme for growing the Tor network other than cold crypto cash.

You're stupid

Everybody knows you're not supposed to use torrents with tor, right?

But the problem there is using existing bittorent clients and how they leak IPs to trackers, etc. Drop those stones for a second and hear me out. We're not proxying traffic from regular bittorrent clients through tor, we're making something new.

Onion Popcorn

Say we do the following:

  1. Make a DHT that serves out peer onion addresses (OAs?) instead of IP addresses;
  2. Fork Popcorn Time, make it create a hidden service for the user and connect to the OA DHT to fetch peers;
  3. Connect to peers via their hidden services.

Stop righ there, you'll break the network!

Oh, I forgot: 4. Make the Popcorn Time fork also be a relay by default* whenever possible.

Nobody would agree to do this on the main tor software for a thousand reasons, but it's an app and you can decide to do that in it independently. If you're going to add a lot of load to the network, you have to give back.

This "Onion Popcorn" could also soft-enforce download limits based on the amount of traffic the user has relayed. Sane defaults and interface nudges can go a long way. (Popcorn Time itself doesn't even expose network/bandwidth adjustments to the user and, for the mainstream, we can count on hiding some options as something easier to do than coming up with a proof-of-correctness anti-leeching scheme.)

Bandwidth at first probably wouldn't be enough to stream anything, but otherwise should work for downloading and watching.

The end result is that you're incentivizing Tor "miners" by giving them something they want (so bad, in fact, that it takes up most of the Internet's traffic) in exchange for relaying traffic for the rest of the Tor network.

As a bonus, you end up with a very, very private torrent network that never touches exit nodes.

You'll still break the network!

Even if these torrent nodes are a net positive in terms of relay capacity, this much usage of hidden services would probably put an unanticipated load on hidden service directories and introduction points. That could turn out to be a problem.

With enough demand, though, I think capacity finds a way of taking care of itself. Isn't "the whole Internet is all of a sudden trying to get private!" the thing we want the most? Much better problem trying to scale a network that a lot of people want to use, than trying to convince people to use something they don't see a need for.

If it's something people want, they'll find out about "how to make X faster" and learn that it's based on Tor and that you should become a relay or donate money here so that your connection gets faster.

Oh, and for every 100 new relays, you gain on average X extra kbytes of download speed: help us get to this month's goal of another 100 by donating 5 bucks a month!


All of this was inspired by Ricochet IM (, a hidden-services-based, serverless anonymous chat app by the great @special. You should try it out! I'm (among others) ricochet:2xfy7pfetq2ueyff.

What do you say?

Alright, now back to me being stupid, please tear this idea down :) Thanks!

Cheers, Helder

*: There's an issue with running a relay and a hiddens service on the same machine. Discussion here:

P.S.: you can follow me @obvio171 on Twitter.

P.S.2: comments on Hacker News:

zenware commented Dec 11, 2014

I just had an idea like this except a bit different... I want a torrent tracker & search mechanism that can not be shut down without shutting down literally every participant. And because of that I want it to be impossible (read: very difficult) to determine who the participants are.

If only Tor supported UDP traffic... I'll have to figure out a different way.
But my current concept is to mesh net everything(and somehow securely and privately transfer all data), and everything should be "Torrent Tracker, Some sort of search and filtering mechanism"


Its better if you use this with I2P tor exit nodes may have so so bandwidth but not all middle, gaurd nodes have good speeds. I2P has a larger selection of nodes and also supports UDP.


sounds amazing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment