Optional Tor Send/Listen Functionality

[yeastplume]

(Updated with current instructions, Oct 4th, 2019) these are the basic instructions to set up and test:

• To Pull this PR:
  • git fetch origin pull/226/head:my_tor_test_branch
  • git checkout my_tor_test_branch
  • cargo build

To Listen

• Install tor on a target machine, and ensure the tor executable is on the PATH (to test this, just type tor at 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 listen

That should be it, if tor is installed and on the path, your hidden service address should be printed to stdout. 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 forgrin-wallet.toml (this will be output for new wallets, note send_config_dir is full path). For backwards compatibility reasons, if this section doesn't exist in grin-wallet.toml these are the defaults that will be assumed, with send_config_dir configured 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"

TODOs (for this PR, more TOR related work is ahead):

• Windows/Mac
• Decide derivation path for hidden service address. Currently uses 1/0/0 and unhashed secret key as input to ed2559 pubkey generation for no real reason. This PR will only aim to expose one address, with multiple addresses in a future PR depending on what's decided. (See comment in Online Transacting via TOR Hidden Services grin-rfcs#24 (comment))
• Consider what to do when running owner api and foreign api on same port -- will leave this for future consideration.. you'd assume nobody would want to expose both the owner and foreign APIs in the hidden service.

[quentinlesceller]

Awesome. That was fast!
Two comments before discussing it further on Keybase:

• What about removing the http and .onion in the send parameters for Tor so we can have a "cleaner" send command? grin-wallet send -m "tor" -d tuyadexmtd5houbmysg5qqctor43npeqmeibwmrml55spidwudi4egid 60.
• What about making a repo for the hyper 0.12 SocksV5 connector so other can use it.

[yeastplume]

Awesome. That was fast!
Two comments before discussing it further on Keybase:

• What about removing the http and .onion in the send parameters for Tor so we can have a "cleaner" send command? grin-wallet send -m "tor" -d tuyadexmtd5houbmysg5qqctor43npeqmeibwmrml55spidwudi4egid 60.

Sure, the URL parsing expects an http URL in many places, so just left it as is for now, can change it soon

• What about making a repo for the hyper 0.12 SocksV5 connector so other can use it.

That means documentation, setting up tests, completing it (it's missing some functionality that we don't particularly need) and maintaining it. It's the right thing to do (tm) but going to put it on a low-priority thread (also tm).

[yeastplume]

Updated top comment with most recent instructions

[DavidBurkett]

This approach works fine, but it won't work as well for on-the-fly changes, like the user requesting a different receive address. In Grin++, I'm opening a tor control socket(https://github.com/torproject/torspec/blob/master/control-spec.txt) and using the AUTHENTICATE, ADD_ONION, etc APIs to allow that sort of thing to work more seamlessly. Maybe that's not necessary for grin-wallet, especially since we haven't switched to the wallet713-style logged-in CLI, but just wanted to point out that potential limitation.

[yeastplume]

Discussed in keybase, this is mostly because there are no decent client libs in Rust, and this is much easier to implement for the time being (2 advantages in that it doesn't open any extra ports on the listener side and doesn't require keeping track of a password for the control port). Will keep as is for now and see how we get on.

[yeastplume]

No longer draft (so tests will run), but not quite ready for review, mostly because we still need to figure out the derivation path.

[yeastplume]

Think this is pretty much ready for review/merge into master. Nothing here is necessarily final as the 3.0.0 release is a ways off still, but would be good to get this into master so people can start experimenting with it.

[yeastplume]

Made sending via TOR work more implicitly, automatically running the tor listener if tor is available, and added config + commands to turn this off if desired. Send command will figure out if address is a valid onion V3 address, and will attempt to send via TOR if so.

Merging once tests pass.

[zedansk]

Test