Make Sia Tor-Enabled

[GlenDC]

The main idea is that peers can be run as hidden services, and that peers receiving incoming connections from peers ran as hidden services can still be connected to (even though this will have to be done via a Tor Proxy).

Currently the Gateway has following Version Header (sent as the initial handshake procedure):

type versionHeader struct {
	Version   build.ProtocolVersion
	GenesisID types.BlockID
	UniqueID  gatewayID
	WantConn  bool
}

However I believe we may want to extend this to at least:

// IPv4/IPv6 /Onion Address
type NetAddress [16]byte

type versionHeader struct {
	Version     build.ProtocolVersion
	GenesisID   types.BlockID
	UniqueID    gatewayID
        AddressFrom NetAddress
        AddressTo   NetAddress
	WantConn    bool
}

Whereby the AddressFrom is the most important one for this issue, as it would allow us to check which address the peer believes its from. This is especially important, as this way we would also be able to detect if it needs to be connected to via a proxy.

As part of a solution of this issue I would therefore want to propose that we from now on store and exchange all net addresses in IPv6 format:

• An IPv6 address remains unchanged, so nothing to do for that one;
• An IPv4 address is mapped to an IPv6 address, by simply prefixing it with zeroes (see: https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses);
• An onion address can be mapped to IPv6 by prefixing it with a constant prefix, to turn them into a Unique Local IPv6 Unicast Address (as described in https://tools.ietf.org/html/rfc4193), I propose we simply use the fd87:d87e:eb43::/48 IPv6 range for this, as that network range is also used by Bitcoin, which on its turn took inspiration from OnionCat. Either way the specific range isn't too important, as long as we stick to it, based on the ideas described in RFC4193;

Using this new Version Handshake, we can then check the address from the other peer (AddressFrom) and see if it has a specific prefix that indicates we want to interpret its address in a specific way, telling us perhaps also more about the type of connection we want to make.

This would allow other peers to run as a hidden service, and let us know they do so, by specifying their public key (onion address) as an IPv6 address (AddressFrom). The receiver of this header would then remove the prefix, and use the lower 80 bits as the public key (as a public key is simply 80 bits of base32 encoded data AFAIK). Knowing that the other peer is run as a hidden service, this peer also has to make sure a Tor Proxy is running, dial that proxy, and dial the public key via that proxy (see: SOCKS5).

In theory we could make this Tor Proxy support optional, and any peers not Tor-enabled could simply block such incoming connections due to not supporting them.

If for some reason a peer is not aware of this Tor Network Address, it would simply think it's an IPv6 address, try to connect to it, and fail. No harm done. But I don't think there is any reason that any peer should ever get into this situation, even though it wouldn't be harmful.

On top of this proposal we would also want to add some extra CLI flags, which allows a user to make her siad Tor-Enabled, and optionally run behind an hidden service itself. The hidden service can either be configured via the torrc configure file, or we can even support to create a ephemeral hidden service via tor's socket API (see: https://stem.torproject.org/api/control.html#stem.control.Controller.create_ephemeral_hidden_service).

I would want to start working on this ASAP. As you can see from my proposal, this idea would again need to extend the version handshake, and we are already doing that anyhow in the gateway-proto branch, the time is ripe to do it now.

[starius]

Currently peer tells its port to connect back.
As the type of that variable is string it can be extended to hold onion address as well, e.g. hss3uro2hsxfogfq.onion:9981. This doesn't require changes of the wire format.

[starius]

At any rate I really like the suggestion of making Sia Tor-enabled.
Hosts located in onion domain are much harder to seize.
Also peers located in onion domain are much better for anonymity of transactions.

[DavidVorick]

Tor is not going to help all that much with anonymity of transactions, unless your whole identity (all incoming and outgoing transactions) live exclusively in Tor. Blockchain analysis is very strong, and if you ever spend your Tor-money in the real world, it can be traced to you forensically unless you really know what you are doing.

But, it can help hide your ip if you are a host. Not sure how the Tor foundation would feel though about a system designed to move massive amounts of data around leeching on a volunteer network.

[lukechampine]

Closing for now. We can revisit this once we have serious intent+resources to devote to Sia-over-Tor.