Tor support about rivine HOT 2 OPEN

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 his rivined 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).

from rivine.

@GlenDC Is a peer able to expose itself over both ipv4 and ipv6?

from rivine.