Lnd: Respect users choice of network.

[qubenix]

Currently the code handles re-connection to peers by using the first address advertised by the peer, possibly disregarding the fact that an onion address was the original connection method.

https://github.com/lightningnetwork/lnd/blob/74e9852e3df0172d320c2c500b1849be3e4f14b4/server.go#L2907-L2918

There are many reasons one may want to connect only via the Tor network. A few are:

• Tor provides end-to-end encryption only to onion addresses.
• Avoid malicious exit nodes.
• Preserve the resources of useful exit nodes.

One option is to somehow remember that the connection was initiated to an onion address and then check for one of those first, but there's no way to know if the user is willing to default to a clearnet ip address (personally I am not) if the onion no longer exists.

Remembering the onion address is not helpful either as it is a best practice to use ephemeral onion addresses. Even though most users and applications don't follow this practice (yet), it's just not reliable. For instance, a user could delete their onion private key from the datadir and end up with a new onion address by accident.

I suggest to add a setting onlynet=, this will give users the choice to remain in whatever network(s) they like.

From bitcoind:

-onlynet=<net>
       Make outgoing connections only through network <net> (ipv4, ipv6 or
       onion). Incoming connections are not affected by this option.
       This option can be specified multiple times to allow multiple
       networks.

[seth586]

In addition, if tor=active, lnd should prioritize onion addresses if a peer also advertises ipv4/6.

[Crypt-iQ]

@qubenix

I think the onlynet flag might not make sense:

If I have an ipv4 connection to a channel peer and then restart with onlynet=onion, what happens if they don't have a tor hidden service? Given that there aren't many lnd-run hidden services, imposing the requirement to connect to only HS seems overkill.

The fetchNodeAdvertisedAddr function is only called for inbound peers, so we were not previously connected to their hidden service. One alternative that I'm wondering might work for your use case is if tor is active:

• In the fetchNodeAdvertisedAddr function, check for an onion address and try connecting to that. Otherwise connect to their clearnet IP over tor. This could also be done for disconnected outbound connections if we were previously connected via ipv4/6 and then they created a HS.
• In establishPersistentConnections (when persistent connections are established on startup), instead of attempting a connection to all possible advertised addresses, only try an onion hidden service connection.

[qubenix]

If I have an ipv4 connection to a channel peer and then restart with onlynet=onion, what happens if they don't have a tor hidden service?

Refuse to start with an error. Warn user why this is bad, and inform them to close channel with that peer first or start without that setting.

Given that there aren't many lnd-run hidden services, imposing the requirement to connect to only HS seems overkill.

Yes, but number go up. 1,794 nodes (39.5% of network) at time of writing.

The fetchNodeAdvertisedAddr function is only called for inbound peers, so we were not previously connected to their hidden service.

Maybe I quoted the wrong code. My issue is that I've experienced situations where I initiated connections to a peers via their onion address, only to reconnect to their ipv4 after rebooting my node. Even though their onion address still exists.

IMHO, your alternative suggestions should be implemented as a bare minimum. I would still like to see onlynet=onion.