Re: [tor-talk] Putting the "Tor" back in Torrent

[Zenaan Harkness <zen@xxxxxxxxxxxx>]

On 7/12/14, Helder Ribeiro <helder@xxxxxxxxx> wrote:
> How a Popcorn Time fork could incentivize people to run thousands of
> new Tor relays
>
> https://news.ycombinator.com/item?id=8022341
>
> Thinking about NAT traversal as Tor's killer feature lead to this
> discussion: https://news.ycombinator.com/item?id=8018213
>
> **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[1].**

Sounds great to me. Thank you for laying out the thought this clearly.


> ## Onion Popcorn
>
> Say we do the following:
>
> 1. Make a DHT that serves out peer onion addresses (OAs?)
> instead of IP addresses;

One OA per:
- client/peer? or
- per torrent? or
- per shard/ sharing block?

It may behoove us to consider privacy implications, and may
be simple to maximise privacy/ frustrate correleation attacks.

The client is operating to some degree as a "sharding" cache
server.

The copyright cartel consider that an illegal thing to do.

It is in our interests to maximise privacy.

Plausible deniability may be increased with:
* Another concept: opportunistic shard caching,
dependent on network demand;
Tor has some infrastructure/ protocol stuff in regards
to this (HSDir nodes).

This client is a Tor relay "serving" anon hidden services
(specifically torrent peers).

Given bandwidth constraints and sharing defaults etc,
this client could _opportunisticly_ cache excessively
popular shards, to provide:
- plausible deniability
- network capacity increases


----
Infrastructure requirements:
Increases in clients must result in corresponding
increase of "network infrastructure capacity", including:

- network throughput - each client defaults to a relay

- dht capacity - each client participates in torrent dht

- hidden service directory/ lookup capacity - each client
operating immediately as a HSDir, at least for these Torrents;
this might require a separate HSDir namespace for torrents
(please speak with Tor gurus on this one sorry not me),
hopefully not, but who knows - Tor network currently has some
centralised components which must be considered since we are
talking potentially orders of magnitude increase in clients.

- other network scaling pain points to consider ??


> 2. Fork Popcorn Time, make it create a hidden service for
> the user and connect to the OA DHT to fetch peers;

In the past I thought that if a particular torrent client
(I am only familiar with the Java-based Vuze/azureus)
provides the ability for plugins to replace all core features
(dht lookups, network access, storage etc),
then all those parts of the puzzle could be more easily
replaced one by one, the modular design (of Vuze say) making
the development of a proper Tor/torrent thing more easy.


> 3. Connect to peers via their hidden services.

All connections must always be to hidden services only.


> ## 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.)

AIUI, Tor also has some built in mechanisms at its network layer,
to encourage contributory network behaviour.


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

I disagree. Strongly.

*Abundance is an engineering problem.*

You heard it here :)

We see the proof of this in the success of Bittorrent software.

When the design is appropriate to the problem,
abundance is built in, and _does_ provide the needed results.

It is important however to consider current technical
"potential limitations" in the current Tor network design -
namely, at least some part is centralised.

The directory/ network concensus stuff needs to be decentralised
(ie more torrent like) for this; design possibility:
torrent-share the directory "blobs" and merely get signature/
certification keys from the centralised "Directory" servers to
verify the current directory concensus "blob" that you got
(and verify that it is "recent" enough etc etc).

If these changes can be shown to reduce network privacy,
then it might be that the goals of a bittorrent_tor client
conflict with the goals of the Tor network.

That is, there might be a fundamental conflict between
privacy and _instantaneous_ network joining.

I don't know sorry.


> **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.**
>
> To boot, you end up with a very, very private torrent network that
> never touches any exit node.

The goal is very laudable.


> ## 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.

Yes which is why all such parts of the network need to be fully
decentralised - able to be provided by each tor_torrent client.


> With enough demand, though, I think capacity finds a way
> of taking care of itself.

No. And yes. The point is, *with the right design*, capacity
will take care of itself.

That implies there may well be a little bit of work to do
on the Tor network layer.

Of course, this tor_torrent client might just be the driver
to speed that process.

Doesn't sound complicated to me, but I am not a Tor developer.


> ## What do you say?

Go for it. I believe it will take our most popular free
speech network (tor) to the next level, and quite possibly
close to the ideal position for free speech networks in
general - ubiquity.

Regards
Zenaan
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk