connectivity to earth (public zerotier network) #8434

direct connectivity to bitcoind is often problematic due to NAT/firewalls/etc, and onion routing is slow and overly complex (and not very private any longer anyway). Zerotier routing seems to be much faster by comparison and bypasses many networking issues. They provide a public network where anyone can join, using an IP address range which exists but which is not accessible from the internet directly.

I would like to submit a pull to make it easier to use zerotier earth IP addresses, but in order for the seeders to identify nodes on these addresses as up bitcoin needs to distinguish between regular IP addresses and zerotier networks. Is there a style standard for doing this?

It looks like it's just a non-standard VPN protocol. But look at how we currently do IPv4 and Tor.

See also #2091.

I'm the original author of ZeroTier and founder of ZeroTier, Inc. Someone tipped me off to this thread.

We'd be happy to help with this if there is any interest and to answer any questions. Also happy to help with implementation, testing, etc.

Might also want to look at:

https://github.com/zerotier/ZeroTierSDK

This would allow direct embedding into Bitcoin itself without any kernel modules or other third party dependencies.

concept NACK

@adamierymenko I think most people won't want Bitcoin to become bloated by incorporating network code itself, but if there is a simple way to interface with network code (e.g. Onion control port) then this is simple enough to be included. I do think that ZeroTier would benefit greatly from providing some sort of built-in firewall, especially with public networks like Earth. Encouraging people to connect to Earth isn't something I would currently do unless they could specify prior to connection which ports they would like shared/accessible, which in the case of bitcoin is port 8333.

After reading this (https://web.archive.org/web/20190128064602/https://www.zerotier.com/misc/BorderNone2014-AdamIerymenko-DENY_ALL.pdf) I think @adamierymenko might be onto something.... worth having a look at, IMHO

This also addresses some issues being discussed elsewhere, such as authentication with bitcoin nodes, etc.

Closing this, seems to be little interest (not meaning this is a bad idea but I don't see this happening in the forseeable future, but it may once the P2P protocol hurdle is overcome). "P2P protocol needs wider address support" is sufficiently covered by:

• #2091 Binding to multiple anonymous networks (esp. I2P)
• #9214 ensure ADD_ONION implementation is compatible with upstream changes, next generation onion addresses

@laanwj I still think it's worth supporting some other network in addition to tor. Zerotier Earth provides latency about 75% less than TOR's latency, and there are many networks where direct p2p is not permitted - so currently TOR is the only available option.

@rebroad FWIW since a short while it supports I2P as well see #20685. Support for other overlay networks is imo welcome as long as they are relevant/known enough and it is not too much of a burden to maintain.

I've used zerotier for years as an easy to set up L2 VPN, and it really is very nice. For zerotier earth though, it might be best to support it by calling a generic RunCommandParseJSON hook. Similar to how the signer uses a simple command line protocol to enumerate devices and sign transactions, network code could use a simple command line protocol to start/stop accepting connections and get address information. Then zerotier or other network support could be added with external scripts instead of c++ code that needs to be reviewed and maintained here.

I could also imagine a RunCommandParseJSON networking hook being useful for simulations and testing.

@laanwj I'll test I2P to see how it compares. thanks.

The main risk with Zerotier Earth is that it could expose a node to hackers as it creates a new interface that programs might listen on by default (Windows 10 is awful at this) - whereas tor allows only incoming connections that have specifically been configured.