November 13, 2018
142 XMR
0 contributors
Add support to Monero daemon for broadcasting new transactions received over RPC to privacy preserving p2p connections to conceal origin IP. This proposal will use Tor hidden services, but the implementation will be written such that additional anonymity networks (Kovri?) can be added in the future.
Tor can be used today via exit nodes. The issue is the potential for MitM attacks on the data, and blacklisting of the exiting nodes (to help facilitate surrounding node attacks). The recommendation is to use hidden service nodes, like Bitcoin. Users can already force traffic to Tor exit nodes through other techniques.
Lee Clagett (vtnerd) will be the sole implementer. I have experience contributing code to the Monero daemon, contributing to wallet implementions (simplewallet, mymonero), and vast protocol experience. I am also familiar with some of the literature on privacy networks (this should be obvious in the proposal section).
Sending transactions can be traced to their origin by ISPs, or other institutions that connect to many peers to trace the first appearance of a transaction. An entire project, Kovri, has been funded to help mitigate this issue. There are things to implement on the Monero side to make use of an anonymity network as well which will be completed with the Tor integration.
The proposed rate is 50 USD/hour @ 100 XMR/USD for a total of 142 XMR. The proposal will be implemented in three stages:
Provide a sock 4a client implementation. A standard library is less desirable - Tor has some extensions for DNS lookup that will be useful in the future. The delivery for this milestone will not be the ability to force all connections to a specific proxy (that is possibly left for a future FFS). The added functionality of this milestone:
--anonymizing-proxy tor,ip:port which is only used for outbound Tor addresses.--add-peer in onion address format will only be used by the --anonymizing-proxy connection.--add-exclusive-node will work with onion addresses. Users could create a private testnet over Tor or a private mixed testnet.--anonymous-inbound tor,ip:port which should only be used by advanced users. This unique ip/port will let the Monero daemon know what connections are coming in from a Tor hidden service setup.--anonymous-inbound will have a restricted command set that can be expanded in the future. Most likely only control commands and broadcast transaction. Preventing spamming over Tor is a bit harder since public keys are cheaper to create than IP addresses.--anonymizing-proxy tor,... and --anonymous-inbound tor,... will be considered isolated from the others.After milestone 1, users can test broadcasting over Tor by creating a Tor hidden service manually. It is not recommending at this stage on livenet, because timing analysis is a real threat with Monero transaction volume. Expected time: 120 hours (60 XMR).
A well-known weakness of Tor is the lack of delay in data transmits. This has the side effect of leaking the timing of data transmits through the Tor network, and sometimes the size of a message being sent (if the link is often idle). This timing issue can result in the leaking of transaction origin purely by watching the timing and volume of traffic being sent over Tor. This is particularly problematic with Monero having a lower transaction volume than Bitcoin. This milestone will implement the following:
After this milestone, people could use Tor to broadcast transactions safely. Expected Time: 160 hours (80 XMR). A considerable amount of time may be necessary for research, and not leaking transactions across these zones.
I will have to work with the Monero core team to set this up. This will be similar to the hard-coded seed/bootstrap nodes used for connecting to the Monero network for this first time. These will most likely not be operated by me. This will allow --anonymizing-proxy to work without specifying a Tor --add-peer.
Expected time: 4 hours (2 XMR). Will need additional resources from the community to run the hidden service.
Setting up a Tor hidden service will require manual configuration of Tor. A future FFS proposal can implement the Tor control connection protocol (like with Bitcoin). Additionally, this proposal will not provide support for completely hiding the usage of a Monero daemon, because that requires significant additional work to never make a connection outside of Tor.
View community discussion, comments, and proposal updates on GitLab
To be paid: 60.00 XMR
Completion date: 28 January 2019
To be paid: 80.00 XMR
Completion date: 09 August 2020
To be paid: 2.00 XMR
Completion date: 29 November 2020
Funds Awarded: 60
Date: 25 June 2019
Funds Awarded: 82
Date: 24 December 2020