Throughout Grin’s development, it was really never the intention that exchanging transactions via HTTP would indefinitely remain the default preferred method for exchanging Grin. Its current inclusion is more a reflection on the current state of Grin’s development. Grin is a very young, very experimental coin, and HTTP was quite frankly the simplest method of enabling the transaction interactivity requirement at the heart of Mimblewimble during early development. The privacy and (usually frustrating) UX issues of using HTTP wallet listeners are fairly apparent. You currently need to have a good grounding in web server configuration to run a grin wallet listener, and without taking extreme steps you’ll be leaking all sorts of identifying information about your location via your IP. These issues are obvious to anyone currently transacting via Grin.
What isn’t obvious is what the alternative should be. Over the past few months, the wallet subteam has had plenty of lively discussion about the best approach to simplifying Grin transaction exchange and improving the user experience. We’ve considered all sizes and shapes of overlay networks, including i2p, TOR, and several (mostly highly theoretical mix networks). What’s evident is that there is no perfect fit here. Each approach has its advantages and disadvantages (some worse than others,) and it’s clear now that waiting for (or even trying to develop) the perfect overlay/mix-network for Grin would pointlessly stall Grin’s progress, particularly when some solutions exist today that will theoretically get us 60% or 70% of the way towards where Grin needs to be from a UX perspective.
As outlined in the in-progress TOR RFC proposed by @david, providing the option to send and listen for transactions via TOR hidden (onion) services is a logical first step toward improving the transacting experience.
The benefits of using TOR to perform transaction exchanges are many, including:
- The TOR network actually exists today, which is not the case for most mix networks that theoretically suit more of Grin’s needs.
- There is no need to configure web servers or deal with firewalls to run a listener. The only thing you should need on the target system is to ensure TOR is installed, and that your access to the TOR network isn’t blocked by anything.
- All requests are end-to-end encrypted by default, and transfers are much harder for eavesdroppers to trace.
- Your TOR wallet address(es) is(are) derived from your wallet keychain, meaning you can provably identify your wallet without revealing any information about where it’s located. Payment proofs which use TOR wallet addresses are under development.
Some of the downsides are:
- Not every platform has simple access to TOR, particularly mobile devices (and iOS very particularly).
- Access to TOR can be (at least partially) blocked at the corporate or government entirely level
- It does not solve the ‘offline’ transaction problem (which will require further development on top of TOR functionality)
- TOR is now a dependency which needs to be on the target system (which can be dealt with via packaging, which we’re looking at for upcoming releases).
TOR integration into the wallet is a first-step toward seeing how viable it would be make it the ‘first-class citizen’, and promote its use to the exclusion of all other current methods of exchange (particularly raw HTTP listeners). The functionality is experimental, but we hope that the more pioneering members of the community will try it out in the wild and give us feedback on how well it works for them. Instructions on how to try out TOR for Grin transaction exchange are below… please consider giving trying it out and letting us know how well this approach works for you (and please start with floonet or with small amounts of Grin!)
The functionality to send and listen for transactions via TOR is now available in the current master of grin-wallet. The master branch is fully compatible with the upcoming 2.1.0 release, the only difference being that sending and listening will attempt to use TOR if it’s available on the system. Please note that this functionality is experimental and very subject to change before an actual release.
Also note that listening via TOR still opens an http listener, however this http listener only needs to be exposed to localhost (which it does by default). TOR proxies this listener via an onion hidden service address, which is what you provide to senders.
This should work on All 3 major platforms, (assuming you know how to install tor and set up paths correctly)
- Build grin-wallet from master :
git clone https://github.com/mimblewimble/grin-wallet.gitcd grin-walletcargo build
To Listen
- Install tor on a target machine, and ensure the tor executable is on the PATH (to test this, just type
torat the prompt and check if it starts up). Note: you do not need to run tor manually when sending via the wallet, this is just to ensure the executable can be found - Run
grin-wallet listenas usual
That should be it! If TOR is installed and on the path, your hidden service address should be printed to the log via stdout. (This is the address you send to someone who wants to interact with your wallet) If not, listening will fall back to standard HTTP only.
To Send
-
Install tor on the target machine as above
-
The usual send command will check whether the provided destination is a tor address, and send via tor if so. For instance:
grin-wallet send -d "http://tuyadexmtd5houbmysg5qqctor43npeqmeibwmrml55spidwudi4egid.onion" 60 -
This will also work with just the onion address:
grin-wallet send -d "tuyadexmtd5houbmysg5qqctor43npeqmeibwmrml55spidwudi4egid" 60 -
The following is the default tor configuration section for
grin-wallet.toml(this will be output for new wallets, notesend_config_diris full path). For backwards compatibility reasons, if this section doesn’t exist ingrin-wallet.tomlthese are the defaults that will be assumed, withsend_config_dirconfigured to the top-level wallet directory)
#########################################
### TOR CONFIGURATION (Experimental) ###
#########################################
[tor]
#Whether to start tor listenere on listener startup (default true)
use_tor_listener = true
# TOR (SOCKS) proxy server address
socks_proxy_addr = "127.0.0.1:59050"
#Directory to output TOR configuration to when sending
send_config_dir = "/FULL/PATH/TO/TOPLEVEL/WALLET/DIR/tor/sender"
