Tor incentives research roundup: GoldStar, PAR, BRAIDS, LIRA, TEARS, and TorCoin

by robgjansen | July 14, 2014

There has been a considerable amount of work in the area of Tor incentives since the last post on the topic in 2009 (over 5 years ago!). This post will give an overview of some of the major new approaches, including two new designs that I co-authored that will appear at the Workshop on Hot Topics in Privacy Enhancing Technologies later this week. Before getting to those, I'll give background on Tor and discuss some of the social issues to help form a foundation of understanding.

Tor’s volunteer resource model

The Tor network consists of a set of relays that provide bandwidth and other resources to forward traffic for Tor users. Anyone in any part of the world can contribute to Tor by downloading the Tor software and configuring it to operate in relay mode. In fact, the Tor network is currently composed exclusively of such voluntarily-operated relays.

There are many reasons existing relay operators might contribute to Tor. They may contribute because they really want a privacy-enhancing communication tool like Tor to exist, they believe in Tor’s philosophy of open source software and operational transparency, and they want Tor to succeed at its goals. They may wish to be part of the Tor community and the social movement to provide privacy-enhanced communication that connects people in all parts of the world. Tor may be practically useful to them for communication with others or to retrieve content that may otherwise be unavailable to them due to censorship or other network interference. Or they may be technically interested in the Tor software or network and the associated research problems raised by large, distributed systems. Finally, some may be interested for adversarial reasons, e.g., collecting information on the uses of the network or the content being transferred. All of these reasons provide intrinsic motivation for operators to contribute - they don’t expect any direct compensation for their contributions.

The volunteer approach has succeeded so far: Tor now consists of over 5000 relays transferring between 4 and 5 GiB/s in aggregate. For the most part, this is "organic" growth obtained through community outreach, where volunteers first have personal contact with existing community members and become inspired to help.

Whatever their reason for volunteering, relay operators not only contribute resources from the physical machines upon which their relays are executed, but also contribute the time involved with configuring, updating, and adjusting their relays as both the software and network mature. In many cases, operators also contribute monetarily through the direct purchase of dedicated machines or special fast connections to Internet Service Providers (ISPs), and exit relay operators spend social energy on maintaining relationships with their ISP (to make sure the ISP understands that requests coming from their machines are from Tor).

However, because many people that are otherwise excited about or interested in Tor are incapable or unwilling to incur these expenses, there are far fewer Tor relays than Tor clients (users that use Tor to access content, e.g. via the Tor Browser Bundle, without directly contributing resources to the network). Expanding the set of relays could have many benefits: Tor could become faster, more reliable, and more secure while at the same time distributing trust among a larger and more diverse set of distributed peers. A larger network that is transferring a larger quantity and more diverse types of data will, in general, make it more difficult for an adversary to determine who is talking to whom. This means a safer Tor for everyone.

Incentives and motivation... say whuuuht?

There are many social and technical challenges involved with expanding the set of Tor relays. We focus here on the social issues surrounding how to encourage more people to run a relay in the first place by providing incentives (i.e., rewards) for relay operators, and later focus on how to do this without leaking information or otherwise hurting Tor’s anonymity.

An important social issue to consider is that of maintaining the existing community of operators and how rewards could harm it. The presumption here is that existing relay operators are motivated to run relays for their own reasons - the act of contributing to Tor itself has intrinsic value to them. Then the question is: what would happen if we start rewarding operators through the use of an incentive system?

The answer isn’t clear, and there are at least a couple of forks in the cognitive road with many more questions along the way. First, what would happen to the existing operators who used to feel good about volunteering but are now compensated with a reward that may have extrinsic value? Although the new reward may provide some extrinsic value, will it lower their original intrinsic value enough to cause them to lose their motivation to contribute? Will they continue their contributions but begin to expect the reward, such that if the reward is removed later they would no longer be motivated even though originally (before the reward) they were happy to contribute? Second, is the new group of operators attracted to Tor by the reward somehow less desirable than the existing group, because they don’t care as much about Tor or are more likely to stop contributions and leave the system more quickly than the existing volunteers? Is the fact that they have higher extrinsic motivation than intrinsic make them better or worse operators? Will they be less likely to incur the costs of saying "no" when people ask them to log or turn over traffic? Will they in fact be willing to sell logs if it increases their rewards? Third, how will the new group of operators affect the existing group? If their intrinsic motivation was low enough before the reward that they didn’t contribute, but high enough with the reward that they do contribute, are these new contributors going to somehow shift the "community spirit" into something that no longer has the value that it once had? Will this "crowd out" the intrinsically motivated individuals and cause existing operators to leave (a widely acknowledged theory)?

The answers to these questions are not clear, though speculations abound. One response is that we will never know what will happen until we try it, but if we try it we may not like the result. Another is that if we try it and it succeeds, great; if it starts going badly, we can adapt and adjust.

Researchers and other Tor community members have been interested in the Tor incentive problem because a well-designed incentive scheme has the potential to greatly improve the network (we will discuss several technical designs below). However, because of the many open social questions, it has been challenging for the Tor community to come to a consensus on the path forward. On one hand and as discussed above, many people already run Tor relays and provide valuable service, and the network and bandwidth graphs imply some amount of success in network growth. It would be tragic if the introduction of an experimental reward scheme drove away the existing participants. On the other hand, the number of Tor clients still vastly exceeds the number of relays, and Tor’s bandwidth capacity remains the limiting factor for Tor’s growth.

A simplified model of reasoning

If we consider that relay operators with a higher intrinsic motivation to contribute are somehow more desirable to the network and the community because they care more deeply about Tor and the social movement, then we can consider there to be a trade-off between reward value and the desirability of the operator. The lower the extrinsic reward value is, the higher the intrinsic value a potential new operator must possess in order for the total value to be high enough to motivate her to contribute. The higher the extrinsic reward value is, the lower the intrinsic value may be to still attract the new operator. Under this model, as the value of the reward increases, the number of individuals willing to contribute also increases while their "quality" decreases.

Please note that this is a very simplified model of reasoning and since it does not necessarily reflect reality, not everyone should agree with it. There are many other values in play here as well; for example, motivations change over time as the world changes, and incentive schemes that require significant protocol modifications are more difficult to implement, test, and deploy. Nonetheless, this simplified model may help sort out the issues, and it seems to be consistent with the fact that the Tor community has thus far preferred to grow the network through intrinsically motivated relay operators.

Social rewards

Tor’s volunteer approach has generally been on the conservative side of our simplified model, where individuals with higher intrinsic motivations to contribute to Tor are preferred. New operators have been recruited through social and community-oriented efforts such as explaining how great Tor is and why they should care. This works well for people who are already intrinsically motivated about Tor, such as this guy who tattooed a Tor onion on his arm.

Other relay recruitment approaches for intrinsically motivated individuals include and the Noisebridge Tor Exit Node Project: both operate as independent nonprofit organizations for those people who would like to contribute to the Tor network but for one reason or another are not in a position to operate relays themselves. As discussed in a 2011 post, it is preferable that people who can run their own fast exit relays do so. But the approach of turning donations into fast exit capacity allows those who cannot run their own relays to still contribute to improving the performance and exit capacity of the Tor network.

The more recent EFF Tor Challenge is somewhere on the same side of the spectrum, except it actually offers small rewards as incentives. EFF explains Tor’s importance and users are encouraged to contribute to the network by running a relay. The challenge offers prizes to relay operators as an incentive: name and twitter handle published in a list of contributors, a limited edition sticker for running a relay for 12 months, and a t-shirt if that relay is fast (bandwidth of 1 MB/s or larger after 12 months).

Other social rewards are possible here as well. A post on the tor-dev mailing list proposes that Tor host a simple profile page for each relay that will list and celebrate the relay’s total bandwidth contribution over time, and recognize the operator for running special Tor bridge or exit relays. Relatively simple ideas like this may have the potential to attract intrinsically-motivated individuals without requiring extrinsic rewards or a lot of changes to Tor itself.

The approaches in this category are relatively low-risk/low-reward schemes: even though the new operators are receiving recognition or a reward for running a relay, the reward is of such little value that there is little risk that existing contributors who may not have been rewarded will leave. At the same time, a new operator loses little if it decides to shut down the new relay.

On the other side of the spectrum are more "radical" approaches that do not require individuals with high intrinsic motivation (though they are welcome, too!) but change Tor’s design have been explored by researchers. Researchers explore these designs because they are generally more technically interesting and have the potential to produce a much larger set of relays. We now shift to discussing these latest research proposals.

Review of early research on Tor incentive system designs - Gold Star and PAR

The 2009 post discussed two incentive papers that were new at the time: Payment for Anonymous Routing from PETS 2008 (PAR) and Building Incentives into Tor from FC 2010 (the "Gold Star" scheme).

In the Gold Star scheme, the Tor directory authorities measure the bandwidth of Tor relays and assign a special flag (a "gold star") to the fastest 7/8 of relays. Then whenever those relays send traffic through Tor, they choose the other fast gold star relays to form a fast gold star path. Relays then prioritize traffic on these gold star paths. The incentive here is that if you run a relay, you will get faster service when using Tor as a client. The main drawback to this approach is that only relays are able to get gold stars and priority service. This means that all relays that are part of a gold star path know for certain that the initiator of that traffic is someone from the small list of gold star relays. Because the set of gold star relays would be smaller than the set of all Tor users by several orders of magnitude, the anonymity for gold star relays would be significantly harmed.

In PAR, all users (not just relays) are able to be part of the incentive system. PAR has an honest-but-curious centralized entity called a "bank" that manages digital tokens called "coins". Users can purchase coins from the bank and then pay the relays while using Tor; the relays then deposit the coins back into the bank and the bank checks to make sure the coin is valid and that it has never been spent before (i.e., it has not been "double spent"). The main novel idea explored in this work is how to include digital payments into each Tor circuit in a way that prevents the relays from learning the client’s identity from the payment itself.

Adding real money into Tor opens a host of new legal and technical questions, which Roger already briefly discussed. For example, real money might shift Tor into a different legal category (see e.g. the EU discussions of what is a "service provider" and which ones are obliged to do data retention), or change the liability situation for relay operators.

The main design challenge we learned from the PAR design is that the timing of when the client withdraws the coins and the relays deposit them creates a trade-off between the ability to detect double spending and link a client to its coins. If the client withdraws some coins and a few seconds later a relay starts depositing coins, how much information does the bank gain? If the relay waits for some time interval to deposit the coins to hide this timing information, then it becomes possible for the client to double spend those coins during that interval. The longer the relay waits before depositing, the harder it is for the bank to link the coins but the easier it is for the client to cheat. A rational relay will deposit immediately to secure its payment, which leads to the worst situation for anonymity. If we assume the relays will deposit immediately, then it is up to the client to hold coins for some random amount of time after purchasing them from the bank, to disrupt potential attempts to link withdrawals to deposits at the cost of flexibility in usage.

In review, both of these proposals have anonymity problems: the Gold Star scheme because the assignment of rewards to relays is public and identifies traffic as originating from the relatively small set of clients of fast relay operators; and PAR because the timing of the withdrawal by the client and the deposit by the relay may leak information about the client’s traffic. In PAR, coins may be held by the client and the relay longer to disrupt this timing information, but this trades off flexibility in usage and the speed at which double spending can be detected. So what have these papers taught us? We have learned about some requirements that a Tor incentive scheme should probably fulfill: both clients and relays should be able to receive the incentive so that neither group stands out; and the timing of payments should not allow cheating and should not enable linkability.

Preventing double-spending without leaking timing information - BRAIDS

Recruiting New Tor Relays with BRAIDS was the followup research proposal presented at CCS in 2010. One of our goals in BRAIDS was to eliminate the trade-off between double-spending and linkability. To achieve this, we designed a new type of digital token which we called a "relay-specific ticket". Tickets were still issued by a trusted, centralized entity - the ticketmaster (we called it a "bank" in the paper, but BRAIDS was not designed to handle real money). Clients choose which relays they want to use, and receive tickets from the ticketmaster that are valid only at the chosen relays while hiding the chosen relay information from the ticketmaster (using partially-blind signatures). Clients then form a Tor circuit with the chosen relays and send the tickets to receive traffic priority (using a differentiated services scheduler). Each ticket will then provide traffic priority through the chosen relay for a specific number of bytes. Because each ticket a relay receives is only valid at that relay and no other, the relay could prevent double spending locally without contacting the ticketmaster.

Another feature of BRAIDS is that tickets are distributed freely in small amount to any client that asks, but only to one client per IP address, and only once per distribution round. If the clients change their mind about which relays they want to use for a circuit, they may contact the ticketmaster to exchange their old tickets for new ones following a time schedule. The exchange process is also used by relays to turn the tickets they received from clients into new usable tickets.

One main drawback to BRAIDS is that even though all users are able to get a small amount of tickets for free, relays are able to accumulate a much larger stash because they receive the free tickets AND the tickets sent to them by other clients. This means that relays stand out when using tickets to download large flows because it is less likely that a normal client would have been able to afford it. Another major drawback is that the exchange process is somewhat inefficient. Relays will exchange received tickets for new ones which they can use themselves, and clients that didn't spend their tickets (e.g., because their Tor usage was low or their chosen relays became unavailable) must exchange them or lose them. This leads to the ticketmaster exchanging all system tickets over every exchange interval. (The ticket validity interval is split into [spend, relay exchange, client exchange], so clients that don't spend in the "spend" time-frame must wait until "client exchange" time-frame to get new tickets. Increasing the interval lengths make them slightly less flexible to rapid changes. The longer the intervals, the more tickets will "pile up" for later processing by the ticketmaster.)

BRAIDS showed us the power of relay-specific tickets but unveiled the scalability problems associated with a trusted, centralized entity.

Improving scalability - LIRA

LIRA: Lightweight Incentivized Routing for Anonymity was published at NDSS 2013. LIRA still uses a centralized entity to manage the incentives, but LIRA only requires incentive management for the relays (thousands) instead of for all system users (millions) like BRAIDS. The way we achieve this is through the use of a lottery system, where clients could simply guess a random number for every circuit to receive priority on that circuit (traffic is prioritized using a differentiated services scheduler as in BRAIDS) with tunable probability. The lottery is set up with special cryptography magic such that relays are rewarded with guaranteed winning guesses to the lottery; relays are allotted winners according to the amount of bandwidth they contributed.

LIRA is more efficient and scalable than any earlier scheme. However, LIRA’s main drawback is that probabilistic guessing reduces flexibility for clients wanting to receive continuous priority over time, and creates a potential for cheating the system because it enables clients to continuously create new circuits and new guesses until a correct guess is found. Another problem is that a secure bandwidth measurement scheme is required to ensure that relays don’t receive rewards without actually contributing to Tor (this wasn't necessary in BRAIDS because the clients sent rewards (tickets) directly to the relays); secure bandwidth measurement is still an open research problem. Finally, LIRA still relies on a trusted central entity to manage the lottery.

Reducing reliance on trusted parties - TEARS

From Onions to Shallots: Rewarding Tor Relays with TEARS will be presented at HotPETs later this week. The main goal in TEARS is to remove the reliance on a central entity to manage the incentives. The central entities in the above schemes (let’s generalize them as "banks") are referred to as "semi-trusted", because there are several ways a malicious bank could misbehave - for example, the bank could refuse service, could extort users by demanding extra fees in order to process their requests, or could "inflate" the digital currency (coins, tickets, guesses, etc.) by printing its own tokens for a profit.

TEARS draws upon the decentralized Bitcoin design to address these concerns by using a *publicly auditable* e-cash protocol that prevents the bank from misbehaving and getting away with it. The bank in TEARS consists of a group of semi-trusted servers, such as the Tor directory servers (as opposed to Bitcoin’s distributed proof-of-work lottery), only a quorum of which need to function correctly for the overall system to keep working. The e-cash cryptography used here is publicly auditable and every interaction with the bank is conducted over a public communication channel (such as the Bitcoin blockchain itself). The security guarantee is that any form of misbehavior on the part of the bank servers leaves a trail of evidence that can be discovered by anyone watching. This approach is reminiscent of systems like Certificate Transparency and OpenTransactions.

In addition to a decentralized bank, TEARS offers a new two-level token architecture to facilitate rewarding relays for their bandwidth contributions without hurting anonymity. First, a decentralized process audits relays’ bandwidth and informs the bank of the results. The bank mints new "shallots" (anonymous, auditable e-cash) for each relay based on their contributions and deposits them into the relay accounts on their behalf. Separately, the bank’s monetary policy may allow it to mint new shallots and distribute them to users, e.g. using mechanisms suggested in BRAIDS but more commonly known to Bitcoin users as faucets. Second, shallots are transferable among users and may be redeemed for relay-specific "PriorityPasses", which are then used to request traffic priority from Tor relays (again, as in BRAIDS). PriorityPasses are relay-specific so that relays can immediately and locally prevent double spending without leaking information to any other entity. This is a similar feature present in BRAIDS’ tickets. However, a novel feature of PriorityPasses is that they are non-transferable and become useless after being spent at a relay -- this reduces overhead associated with exchanges, and ensures that the process of requesting traffic priority does not harm anonymity because the act of redeeming a shallot for a PriorityPass will be unlinkable to any later transaction. There is a question of how many PriorityPasses can be spent in one circuit before it is suspicious that a client has so many, so the size of the faucets and how they distribute Shallots will play a key role in anonymity. Anonymity is also tied to how relays decide to distribute their Shallots to clients, either via a faucet or a through a third party market.

TEARS was designed to operate inside the existing Tor network and thus does not significantly change the fundamentals of Tor’s design. The decentralized bank and bandwidth measurement components do not alter the way clients choose circuits. Clients and relays that want to use or support TEARS, however, would need to support new protocols for interacting with the bank and logic for handling shallots, PriorityPasses, and traffic priority.

TEARS still relies on a "bandwidth measuring" component that can accurately and robustly determine when a relay has indeed contributed useful bandwidth. While the e-cash system in TEARS is designed to be publicly auditable, the existing mechanisms for bandwidth still require trusted authorities to probe.

Bandwidth measurement - TorCoin

A TorPath to TorCoin - Proof-of-Bandwidth Altcoins for Compensating Relays is the other paper to be presented at HotPETs this week. TorCoin addresses the bandwidth measurement problem with a different approach -- an altcoin (a Bitcoin alternative) based on a novel "proof-of-bandwidth" (rather than proof-of-work) mechanism called TorPath, in which the relays (and endpoints) of a circuit effectively mine for new coins whenever they successfully transfer a batch of packets. In TorCoin, a group of "assignment" authorities are responsible for generating a list of circuits (using a shuffle protocol) and assigning them to clients. Bandwidth proofs are then constructed as the circuit is used such that the client mines the TorCoin and then transfers part of it to each of the circuit’s participants.

Like TEARS, TorCoin distributes the process of rewarding relays for their bandwidth contributions. Bandwidth measurement is done directly as part of the distributed mining process and provides strong guarantees. Also, by utilizing a group of assignment authorities that may have more information about the system or underlying network, there is a lot of potential for generating more secure paths for clients than clients are able to generate for themselves.

TorCoin still has some issues to work out; it may be possible to fix some of the smaller issues with protocol modifications, but some of the larger issues don’t have obvious solutions.

One drawback to TorCoin is that it requires the group of collectively-trusted assignment authorities (you have to trust only that some threshold/quorum number of them are correct) to generate and assign circuits to clients. This is a similar trust model to the current Tor directory authorities. In practice, the assignment authorities cause availability issues: if a majority of the assignment authorities are unreachable, e.g. due to DoS or censorship, then the system is unusable to the clients because they won’t be able to generate circuits. This is also somewhat true of the directory authorities, however, directory information can be signed and then mirrored and distributed by other relays in the system whereas assignment authorities are required to always be online and available to new clients. TorCoin clients contact the assignment authorities in order to build new circuits, whereas in Tor they can build as many circuits as they need once the directory information is retrieved (from the directory auths or from directory mirrors).

TorCoin as written has significant security issues. Because relay assignment is not based on bandwidth, it is easier for an adversary to get into the first and last position on a circuit and break anonymity. This can be done through a sybil attack by adding an arbitrary number of bad relays and joining them to the network without actually providing bandwidth. Because the protocol reveals which ephemeral keys are attached to the assigned circuits, an adversary can confirm when it has compromised a circuit (has malicious nodes in the correct positions) without needing to do any statistical correlation attack (it can match up the ephemeral keys assigned to its malicious relays to the ones posted in the circuit assignment list).

The formation of relay/client groups is not discussed and is similarly vulnerable to sybil attacks where the adversary can completely subvert the coin mining process. This can be done by registering an arbitrary number of relays and clients with the assignment servers, such that a large majority of circuits created by the assignment process will contain malicious relays in all positions and be assigned to a malicious client. This malicious collective of nodes can then “pretend” to send bytes through the circuit without actually doing so, and gain an advantage when mining coins. The paper suggests to use a persistent guard, which means the adversary only needs malicious relays in the middle and exit positions of its sybil client circuits, exponentially increasing the probability of a full compromise (or requiring far fewer nodes to achieve the same probability of compromise as without persistent guards). (The sybil clients only have to get 2 of its relays in the circuit instead of 3, reducing the probability from f^3 to f^2 for malicious fraction f.) Further, even if some relays on a circuit are honest, it is not rational for them to refuse to sign proofs of bandwidth that have been exaggerated (too high) by other relays. It will only benefit a relay to ignore proof-of-bandwidth checks, giving it an advantage over completely honest nodes in the TorCoin mining process.

There are a variety of unaddressed practical deployment issues as well. It is not clear how to do load balancing with TorCoin alone - no one should be able to determine how many bytes were sent by any of the circuit members or where the payments for mined coins are being sent (anonymous TorCoin transactions are necessary for anonymity). Exit policies are not discussed, and there is no clear way to support them and for a client that would like to request a specific exit port. Its not clear how to ensure that a relay is not chosen for the same circuit twice, or two relays from the same relay family are not on the same circuit. Finally, it is not clear how to link ephemeral circuit keys to TorCoin addresses so that payments may be sent from clients to relays without revealing client identity.

Don't misunderstand my ranting here - I think that the TorCoin idea is great (I am a co-author after all). It has the potential to motivate new researchers and developers to start thinking about solutions to problems that Tor is interested in, particularly bandwidth measurement. However, the limitations need to be clear so that we don't start seeing production systems using it and claiming to provide security without working through *at least* the issues mentioned above. The current paper was an initial concept in its early stages, and I expect the system to improve significantly as it is furthered developed.

(For completeness, we should also point out that TorCoin will need a new name if anybody decides to build it. The Tor trademark faq says it's fine for research paper designs to use the Tor mark, but if it becomes actual software then it sure will be confusing to users and the rest of the Tor community about whether it's written by or endorsed by Tor.)

Note that TorCoin and TEARS are at least somewhat complementary, since TEARS *needs* a proof-of-bandwidth scheme, and TorCoin *provides* one. However, they’re also not directly compatible. TorCoin requires a substantial change to both Bitcoin and to Tor (or to put it another way, it would be a system that only partially resembles Bitcoin and only partially resembles Tor). On the other hand, TEARS leaves Tor's circuit-finding mechanism intact, and the token protocol in TEARS is closer to traditional anonymous e-cash systems than to Bitcoin.

For better or for worse?

As outlined above, recent research has made great improvements in the area of Tor incentives. More work is needed to show the feasibility and efficiency of the decentralized approaches, and a secure bandwidth measurement scheme would help fill a critical piece missing from TEARS. Recent improvements to the way Tor schedules sockets and circuits would be necessary to correctly provide traffic priority (see #12541), and then a differentiated services scheduler that is able to prioritize traffic by classes (already described in and prototyped for the BRAIDS, LIRA, and TEARS papers) would also be needed.

Unfortunately, it is unclear how to make headway on the social issues. A small scale rollout of an "experimental build" to those relays who want to support new incentive features could be one way to test a new approach without committing to anything long term.

One question that is often raised is: if an incentive scheme rewards relays for providing bandwidth, then won’t everyone just pick the same cheapest hosting provider and Tor will lose location diversity? This question is largely addressed in the discussion of what constitutes a useful service in the TEARS paper (the TEARS paper and appendices also gives useful commentary on many of the common problems and design decisions to make when designing an incentive scheme). Basically, it can be addressed in the monetary policy, e.g., in addition to rewarding relays for bandwidth, the bank could also assign weights that could be used to adjust the rewards based on certain flags that relays possess, or the geographic location in which they operate. This could be adjusted over time so that there would be a higher incentive to run relays in parts of the world where none exist, or to prefer exit relays over other positions, etc. Although, note that it is unclear exactly what the "correct" utility function should be and when/how it should be adjusted. Note that similarly rewards relays for location diversity (see here).

Another point to make here is that most of these approaches have nothing to do with giving out or transferring real dollars. The tokens in most of these schemes are useful only to receive traffic priority in Tor. Will there be third party markets that form around the exchange of the tokens? Sure. And they may be speculated. But at the end of the day, the tokens would still only provide prioritized traffic. Depending on the configuration of the priority scheduler, the difference between priority traffic and normal traffic may not be that extreme. It is conceivable that the tokens would not be worth nearly enough to compensate an operator for the ISP connection, much less the overhead involved with updating the software, maintaining the machine, and talking with the ISP -- and in that case we are still on the more conservative side of the social incentive discussions above.

Tor has some choices to make in terms of how to grow the network and how to position the community during that growth process. I hope that this post, and the research presented herein, will at least help the community understand some of the options that are available.

All the best, ~Rob

[Thanks to Roger Dingledine, Bryan Ford, Aaron Johnson, Andrew Miller, and Paul Syverson for input and feedback on this post.]


Please note that the comment area below has been archived.

July 14, 2014


I find this topic fascinating! I don't understand most of it, but it's still fascinating. Nice work on the post Rob, it's easy to read even for a non-tech person like me.

And I can't help but see some similarity between the this as a 'pay to play' system like prioritized Internet traffic that's been all in the news of late (re: net neutrality). I would be keenly interested to read your thoughts on this.

For example, I could see some group of people with this mindset:
"Tor is not fair because I go slower than other people just because I can't afford (or am not allowed) to help the network, even though I want to do so."

And I could see some other group of people with this mindset:
"Tor is not fair because I give to the network to get good speed, but then other people don't give to the network, they use it for free, which in effect slows down my speed, so why should I help the network at all?"
(Two steps forward, one step back type of thing - granted, one could use the argument that anonymity needs company.)

Best regards.

Net neutrality is a valid concern; thank you for raising it. There are two issues here: (1) differentiating all types of traffic, but dependent on the user; and (2) differentiating different *types* of traffic while ignoring the user.

Tor already does (2) to some extent by preferring low-latency traffic over high throughput traffic (this is done with its circuit priority scheduler). I think this is a good thing because it allows for the management of traffic in order to utilize the existing capacity to benefit the most users possible.

On the other hand, many of the incentive schemes propose to enable (1) for reward purposes. The argument for this approach is that in order for users to "pay" for traffic priority, they have to contribute *at least as much* capacity back to the network, so that the net result is still an increase in overall network capacity. If every new relay gives more than it uses (here, prioritizes), then this is an overall network win.

July 15, 2014


I like tor and I am using it because of its nature as a hacker culture that often somehow is altruistic in its core sense. I would not love to see an ordinary take-but-damn-give-too culture weaving in which is just so ordinary capitalism and that comes with expectations on its users that some for some legitimate reasons cannot and do not want to fulfill. I am very happy that the tor network features a different "flowerpower" culture that does not demand anything from its participating individuals which in my opinion significantly lowers the entry barriers to try and use tor and later become an active volunteer - hopefully(!). Such a policy also gains initial trust into the network from outstanders that might think of using (and/or participating in) it.

For example, I am using tor for years now but never contributed bandwidth. I have occassionally been considering it multiple times but always came to the conclusion that it currently makes no sense for me because first I want to remain as anonymous as possible and because of that I don't want to rent a dedicated server because I would have to handle my credentials to some hosting provider and he would learn that I am finiancially supporting tor because I am running a tor relay with him. On the other hand I could run such a dedicated server at home but then I would have to secure my home network differently and buy a dedicated machine just for my tor relay. I would love to run such a relay but it would not make much sense because my upload rate is just 64k and has remained so for years and is not expandable in my location. My uplink is so poor that it would not make sense to run a relay. Also, I would never want to run an exit relay because of legal issues.

Luckily, others have different views and priorities. For example, they are happy to register with a hosting service and may live in a country where legal problems of running tor exits is less an issue. I am grateful to all those people that behave differently than me but I do not want to be blamed just because I am an individual with different priorities.

It is a very nice thing that the tor network features such a diversity of people and that its longterm goal is so conclusive in nature, namely to provide every human with an easily adaptable technical possibility to remain under the radar of surveillance (justified by whatever reason by whomsoever) so that anyone can live a free digital life if he/she cares.

I think that by providing rewards, incentives, or digital payments you undermine your own ideals because "reward" is a tool of the kind of societies that implements surveillance and control onto its own citizens - which is what they have to because somehow the rewards need to be measured. I am opposed to the whole notion of measuring behavior because then only tor partcipants that comply with your superimposed will (that they should donate at least as much bandwith as they consume) are good participants but the others who for any reason do not comply are the bad ones whose bandwith needs to be controlled. Similarly: only citizens that comply with the leaders will are good citizens others have to be controlled by targeted surveillance.

I agree with you that some people may be in better positions to run relays than others. Most of the incentive schemes do not *require* users to contribute anything; if you don't run a relay, you keep using it the same way you are now and nothing changes. I believe it is a fundamental requirement that Tor remain free for those that cannot run good relays.

The point is that if you are able to contribute, then you can receive priority for your own Tor traffic proportional to your contributions, but with the net effect that the network gets a little bit faster for everyone else at the same time.

With respect to the measurement requirement in order to assign rewards: Tor already measures relay bandwidth in order to come up with the path selection weights that clients use to distribute load across the network. A reward system could simply re-use the measurements that are already being done.

July 15, 2014


Indemnify relay operators -- especially exit relay operators -- against the cost of mounting a defense to criminal charges in their jurisdictions, and you will see more people willing to take on the risk.

Why are you not doing this already?

I think the recent case in Austria settles that issue. Torproject would surely have been more helpful had they been involved earlier and the operator had handled himself more responsibly. In the end it wasn't really about Tor. There's an old saying: "You can't protect people from themselves." That's the rub with indemnification.
I've run a small exit relay here in the US for over a year now. No drama. Don't expect any. I'm satisfied that the project has done a good job of maintaining an apolitical, common carrier posture.
But that's just me. I don't counsel anyone to do this. Go with your gut. If you ain't got the gut, don't do this.

But there's plenty to be done. Do something to help.

Tor has, for the most part, historically taken a conservative approach to implementing new research ideas only after they have had time to be vetted by the research community. The problem in this case is that there are many social questions that are not easy for the research community to answer. It may be that the only way to answer them is to actually try out an incentive scheme, which goes against Tor's conservative approach.

IMHO, its worth discussing how to roll out an experimental version of one of these schemes temporarily for the sole purpose of learning about the social side of things.

July 15, 2014


This proposal makes a lot of sense. I think the hardest thing will be implementation. It seems like you could get a lot of relays that are just in it for the money which would be great for speeding up Tor.

Fascinating! Just imagine smiling friendly faces of NSA/XXX executives. Dont forget newest anonymous advertisement service.
*Refresh you subscription to NewTor(C) in nearest NSA/XXX offices.

July 19, 2014


There is voting system in Tor-Network, is not?

Every node takes a part of traffic, only after a couple of days, weeks. With good health, according to this voting mechanism.

Why nobody see it?

No needs to pay for traffic, no way to mine coins by generation traffic through selfish exit.

Each voting would share out block of money, say 50 TOC ( Tor Coins ), between good fellows only.

There is ready C code in Tor Daemon, see:

* src/or/dirvote.h
* src/or/dirvote.c

July 21, 2014


Hi Rob. I love your post. Some feedback.

(1) Given that in some jurisdictions it's legally precarious for relays to receive "payment" in priority tokens (PTs), it makes sense that the default torrc file specify that any earned PTs are immediately given to a "faucet" which distributes them (evenly?) among all relays or alternatively donates them to TorProject. If a relay operator intentionally modifies her torrc file to do something unwise, that's her choice. As far as I can tell this approach solves all outstanding issues on that front.

(2) There's occassionally talk arguing it's undesirable for PTs to be transferable. I feel Rob's discussion answers this concern. Redeeming PTs shouldn't substantially reduce one's anonymity set---giving our relay operators a chance to damage their anonymity incentivizes only masochists :P

(3) There's some evidence that taking an incentive away does not damage contributions to nebulous public goods such as running a Tor relay. I cite this study of blood donations (Lacetera 2013, section 4.2). However, it remains unclear how a Priority Token Incentive will change the social dynamics. For example, it's likely to make free-riding more socially acceptable (Fuster 2010). Finally, reputation-motivated users should not be damaged by the PT incentive (see "Incentives Reduce Image Motivation" in (Gneezy 2014)) as long as the Pillars/Torati site publicly and clearly distinguishes between operators receiving PTs. We could even have an option where an operator donates some proportion of owned PTs to a faucet/TorProject.

(4) You write, "...and a secure bandwidth measurement scheme would help fill a critical piece missing from TEARS."

Do mean "the" instead of "a" ? Per your discussion I see no downsides of TEARS beyond requiring a yet-to-be-established proof-of-routing.

(5) Thank you for mentioning the "monetary policy" setting a neglibly small priority for PT holders! A common concern I've heard mentioned is that the free tier could become so slow that that Tor becomes a defacto for-pay network. This risk is greatly mitigated, potentially even solved, by the Directory Authorities setting the paid tier to be only an iota (indistinguishably) faster than the free tier. TorProject retains significant control over the benefits of having a PTs simply moving this network-wide default up and down. Although a small fraction of relays will indoubtably patch their clients to ignore the recommended settings from the Directory Authority, it's unclear how much this will affect the individual relays, much less the network.

In almost every discussion of the Priority Token Incentive I've seen a lack of appreciation of the power that comes from TorProject being able to set the default "Priority Policy".


  • Andreas Fuster and Stephan Meier. 2010. “Another Hidden Cost of Incentives: The Detri- mental Effect on Norm Enforcement.” Management Science, 56(1): 57–70.
  • Uri Gneezy, Stephan Meier, and Pedro Rey-Biel. 2014. "When and Why Incentives (Don’t) Work to Modify Behavior"
  • Nicola Lacetera, Mario Macis, and Robert Slonim. 2013. "Rewarding Volunteers: A Field Experiment".

-Virgil Griffith

Thanks for your valuable comments Virgil :) In general, you seem to have a fairly good understanding of the problems here. Thanks for all of the references!

RE (1): I envision that the faucet would distribute tokens to *both clients and relays* in some small capped amount. We did not design a cheating resistant scheme for this, but note that bridge distribution is a similar problem. However, if it is desired that *only relays* receive from the faucet, then I would suggest weighting the distributions by bandwidth contributed.

RE (4): "a" is a defensive article used to allow that there may exist an unknown critical problem that we didn't address. I leave it as an exercise to the reader to find such unknown problems, if they do indeed exist ;)

July 21, 2014


An addition. Although it's true that incentives don't always help, when they won't help is fairly well understood. Many researchers (Gneezy 2014) cite the model from (Benabou 2006) as covering the important components of when the "crowding out" happens.

  • Uri Gneezy, Stephan Meier, and Pedro Rey-Biel. 2014. "When and Why Incentives (Don’t) Work to Modify Behavior"
  • Benabou, Roland, and Jean Tirole. 2006. “Incentives and Prosocial Behavior.” American Economic Review, 96(5): 1652–78.

July 22, 2014


I am personally against the use of a monitory incentive because it would attract *completely* selfish people. If, on the other hand, a "points" incentive is used, similar to Folding@home's, it will encourage friendly competition, and only from people who enjoy that, not from people who have nothing financially to gain. A possible problem I see with any incentive at all is that the fastest relays are not necessarily the best. Would 5 100 mbit relays on the same cheap, but heavily monitored host be better than fewer and slower relays, but spread out and placed more carefully on different, and likely more privacy-conscious hosts? We don't want a culture of "who can be the fastest at any cost", we want "who can help the Tor network to make it faster and harder to break".

Think about it. If you implement TorCoin, as soon as someone finds away to put up 100 cheap, insecure relays which pay for themselves, more and more people will be doing it. Plus that gives the NSA an incentive to blend in and create a massive amount of relays because they could hide it as "well, it's just people taking advantage of TorCoin", even if otherwise there wouldn't be such a big burst.

I may be off on many levels, but that's my $0.02.

July 24, 2014


Please, please, stop posting the ENTIRE text of long blog posts on the home page! Why not adopt the FAR more common approach and post merely the beginning-- no more than two paragraphs? It would only take a single click to read the whole text but it would be so much easier for those wishing to scroll down to get an overview of the different posts on the page, the number of comments for each, etc. As it is now, this requires a tedious amount of completely gratuitous scrolling.

July 29, 2014


"Please, please, stop posting the ENTIRE text of long blog posts on the home page!"

For what it's worth, I have the contrary view. I find the "common approach" to decrease usability and much prefer this blog's approach.

Either way, keep up the good work in maintaining the blog!