OK, so recently the Toroken team won $250,000 to set up an incentives system for TOR.
It got me thinking how one would solve the problems that TOR faces with regards to capacity without compromising security.
For the purposes of this post I assume the reader has a basic understanding of how TOR works and a basic understanding of a mixing protocol like CoinJoin or one of the more advanced methods that Ethereum would make possible.
TOR works by having a group of nodes that pass along encrypted packets to each other that eventually exit the system at a special purpose node called an exit node.
The TOR client selects three nodes at random to route traffic through. It takes the actual packet it wants to send and then encrypts it in layers starting with the last node, then the second, then the first node's public keys. These layers are where TOR got it's name from (The ONION router, "Onions have layers Donkey")
What I suggest is that a contract is set up whereby participants register themselves on the contract by sending funds to the contract using three different addresses. The record of the addresses and their balances are kept in the contract. Funding should ideally take place only from a mix and the contract could be expanded to only accept mixed funds.
The TOR network would then need to be expanded for the following optional functionality to be included; Each layer can (but is not obligated to) include an identity registered on the contract above. This will tell a routing node that this traffic is from the same person who might volunteer this information again, or has done so before. In addition to this identity, the TOR client can also include in random packets, at random layers of the onion, a small transaction that basically consist of the ID, an amount and a signature. The same ID may never be used at a different layer of the onion, if this is not observed, the TOR circuit the client is using will become identifiable.
TOR routing nodes collect these "cash" tokens and at convenient/cost effective intervals, redeem them from the contract.
TOR routing nodes now have an incentive to process packets as quickly as possible, as they may contain "cash". Also they have the incentive to prioritize a specific ID they've seen that has tipped them. Additionally, they have an incentive to prioritize traffic from the node they saw send them the cash containing packet, as that is the circuit the client is communicating on.
They still don't have identifiable information on the ID as the funds went through a mix before it reached the contract. They also cannot see where the packet ultimately ends up or came from, they still only see where it came from immediately before and where they had to send immediately after them (as they do now). They also don't have any incentive to not process free packets, unless their full capacity is being used by paying clients, they will also want to process those packets as it may be clients that might pay.
Funds should be extracted from the contract and remixed as frequently as possible.
Contracts can contain a "charity" pool that allows free traffic to be routed with a reward provided that the charity identities provide a proof of work to prevent a run on the charity pool.