Backward payment as a money pump

[thiennamdinh]

One of the initially discussed ideas was this concept that servers (rather than the client) can pay relays. This could be advantageous for services who would like to improve client connection speeds in order to gain more customers.

There may be a fundamental economic issue where if a server is willing to pay relays for client traffic, then there appears to be nothing stopping a relay from fabricating client traffic in order pay itself. The victimized server would effectively be used as an infinite money pump. My pressing questions are:

• Is this flaw actually fundamental to the concept?
• If not, is there a clever workaround?
• If so, can weaker mitigation techniques reduce the problem to an acceptable level?

[frochet]

Hi Thien-Nam,

Thanks for raising that.

There may be a fundamental economic issue where if a server is willing to pay relays for client traffic, then there appears to be nothing stopping a relay from fabricating client traffic in order pay itself.

Depends on how we design the system, I guess. We might want that Tor clients redeem their coin against a ticket for their particular circuit at that particular time, valid until t with at most b bandwidth. That ticket would not have any value and the relay receiving it should just play the protocol and prioritize the traffic. The problem here is: how can we be sure that the relay plays the protocol ?

If I summarize correctly your issue, it might be written as this property: A relay should not have any incentives of relaying its own traffic, meaning that it will not generate more coins doing that than relaying traffic for others.

Anyway, your issue raise another concern to me: What if Tor clients are able to exhaust Onion service's coins by creating fake circuits and pushing fake requests ? I think that the coin exchange from the Onion service to the client must be coupled with the application level. As an example, let's take facebook again. Facebook might want to give priority to Chinese accounts, Iranian accounts, ect. To do that, facebook must authenticate the user and then be able to tell the Tor layer to prioritize that particular user. IMO, defending against coins exhaustion should be an application responsibility and not Tor's responsibility.

[thiennamdinh]

If I summarize correctly your issue, it might be written as this property: A relay should not have any incentives of relaying its own traffic, meaning that it will not generate more coins doing that than relaying traffic for others.

Yes, that's an apt summary of my concern. The first scheme that you described does seem interesting from a pure Tor traffic control standpoint. One question I have is how do we determine which servers are allowed to distribute bandwidth tickets (and how much) if no incentives are being transferred? Unless the server has to "burn" some amount of cash in order to distribute these tickets? This seems like an important consideration for your second issue as well. If these coins are not valuable at all, then perhaps clients/relays shouldn't have any reason to solicit more than they actually need.

[frochet]

One question I have is how do we determine which servers are allowed to distribute bandwidth tickets (and how much) if no incentives are being transferred?

It would be a new Tor component. Like a directory authority, we just need a few.

Unless the server has to "burn" some amount of cash in order to distribute these tickets?

Yes, it has to destroy the coin and this operation should be verifiable. We might have several of these servers burning coins, distributing tickets and auditing themselves.

This seems like an important consideration for your second issue as well. If these coins are not valuable at all, then perhaps clients/relays shouldn't have any reason to solicit more than they actually need

I am sorry, I am not sure to understand the meaning here. What do you mean by "solicit more" ?

[thiennamdinh]

Okay I understand now, thanks! That makes a lot more sense and seems like a workable feature to me, provided we find technical solutions to some of the issues we mentioned (such as whether we can enforce protocol compliance)

I am sorry, I am not sure to understand the meaning here. What do you mean by "solicit more" ?

By that I mean that clients wouldn't ask for more coins than they need by "creating fake circuits and pushing fake requests". If we go with the approach that you outlined where tickets are only good for a particular circuit at a particular time and bandwidth, then it seems like there is no reason that anybody would want more coins than they need to legitimately access the site.