-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Tor (The Onion Router) is an international overlay network designed for anonymous online internet access and hidden web services. The health and performance of the network is dependent on, among other things, the population of quality relays, which today is largely comprised of volunteers.
MoneTor introduces a freely-flowing (divisible, fungible, and transferable) currency designed to be used for introducing monetary incentives to encourage increased relay participation. Using this virtual currency, Tor clients can purchase on-demand priority bandwidth from Tor relays who may then spend it for their own use or resell the revenue for real-world assets such as dollars or bitcoins.
Attaching incentives to relay operations encourages more financially motivated participants which increases network performance and strengthens security guarantees. A freely-flowing virtual currency allows the system to enjoy the stabilizing dynamics of a free market and opens the door for a brand new space of payments and services.
The motivation to implement an incentive scheme in Tor is broadly built on two contestable assumptions:
- There is a demand for priority bandwidth in Tor
- Monetary incentives would attract new relays
Any violation of either assumption would render the incentive scheme to be useless, for instance if users are perfectly happy with their current Tor access or if adding money to the equation would in fact turn away participating altruistic relays. An informal argument for the first point is that even today, Tor must throttle high-bandwidth traffic such as bitorrent and video streaming, suggesting that there is some demand for bulk network traffic. As for the second point, this is an open question that pits the current altruistic success of Tor against common economic thinking. Unfortunately, the answer is not quite clear at the moment.
However, assuming these statements to be true, the end result (more relays) is undeniably positive. Adding more relays to the network would improve bandwidth and alleviate network congestion. Perhaps more importantly, additional relays would improve the anonymity set of the network, especially in terms of exit nodes where relays would likely be paid at a premium. Many proposed changes to the Tor network also strengthen various security properties at the cost of performance. With a higher bandwidth budget, perhaps some of these improvements can be more seriously considered. These changes could even be implemented preemptively to generate demand for priority bandwidth in the first place, but that may be controversial.
This is only the most basic possible use case for moneTor. In principle, a robust virtual currency native to Tor could be extended for any number of additional uses such as increasingly advanced network services (e.g. extra obfuscation or guaranteed latency), as a built-in mix network for Bitcoin purchases, or as part of targeted geopolitical anti-censorship movements. The key is to maintain full flexibility of the payment system to allow natural adaptions to unforeseen used.
At the economic incentive level, moneTor simply implements a generic virtual currency. The incentive scheme can best be understood by following a typical unit of currency, a mino (tentatively named), through a portion of its lifecycle.
Mint: Minos are simply minted at the discretion of the Tor Project and distributed or sold to Tor clients however the organization sees fit. We will trust the Tor Project to maintain good monetary policy. (note: it might be interesting to think about a more clever way of minting minos as an incentive in itself)
Client: As a client sends network traffic through a circuit, it will be able to transfer a small steady stream of minos to each relay with the expectation that it will receive better service such as priority bandwidth. Note that there is no guarantee that it will actually receive this service, but the client is free to terminate the payment stream at any time.
Relay: Relays will prioritize packets from clients that have sent higher payments. Again, note that relays are in no obligation to do so, but there is no additional cost for prioritizing one data stream over another. A rational relay should stick to the protocol to maximize future payments.
Exchange: Most relays will accumulate far more minos than they can consume for their own internet use and will need a way to redistribute them. While relays could act as their own minos retail distributor, it is likely that some type of currency exchange ecosystem will emerge to allow bulk sums of minos to be sold for other cryto or fiat currencies.
In the context of traffic analysis, we borrow the same threat model from Tor. This model assumes a local adversary who can observe and interfere with a portion of the traffic and can operate and/or compromise a portion of the routers. The scheme is considered secure if the adversary cannot deanonymize a client beyond some bounded probability dependent on the number of compromised routers and traffic data.
From the perspective of the payment scheme, we assume the availability of a consistent public ledger. The adversary is able to observe and post to the ledger as well as observe and modify a portion of incoming requests to the ledger. The scheme is considered secure if the adversary cannot double-spend, illegally create money, or deanonymize either participant in a third-party transaction beyond some bounded probability. Additionally, should the adversary receive a payment, it should not be able to identify the payer beyond some bounded probability.
Importantly, both sets of security constraints must be simultaneously satisfied. For instance, the adversary might use the public ledger to deanonymize a Tor client or use traffic analysis through a compromised router to deanonymize the payer in a ledger transaction.
MoneTor must address several additional performance challenges in addition to the security constraints. Unlike traditional network services (e.g. VPNs) which lump continued access to the service into periodic low-frequency payments, moneTor calls for high-frequency micropayments. The system must perform reasonably well along three metrics.
- Computation: Many anonymous payment systems require heavy crypto; the amortized computation should certainly not be outpaced by the network communication time.
- Message size: The number of bytes required to send the payment should be much smaller than the communication it is paying for.
- Public Storage: Since the financial state of the system will eventually need to be recorded on one common ledger, it is imperative that micropayments are somehow aggregated to occupy the least amount of storage.