search

LNP-WG / lnp-node

Lightning network protocol daemon (suitable for generalized Lightning Network)
MIT License
145 stars 40 forks source link

private or changing IP address considerations #70

Closed nicbus closed 1 year ago

nicbus commented 1 year ago

lnp-node, like any LN node, needs to bind to an IP and port to listen for incoming connections. this means it needs to be reachable from the outside world in order to function properly

this looks fine for some use cases, like a server with a static public IP. other cases might pose some additional challenges, though. as an example, on a mobile device I expect this will not work, due to the fact that most of the time the network configuration will not allow incoming connections to lnp-node (e.g. private IP, filtered port, etc.)

for use cases where a public IP is not available has there already been some planning or implementation?

in LNP networking slides I see "Can pass firewalls (with Tor and UDP hole punching)". has that already been implemented?

moreover, IP and port are used in LNP-BP invoices, which means the IP address may need to be updated if it changes. has this already been considered?

@dr-orlovsky

dr-orlovsky commented 1 year ago

I think the case with "not having a public ip" can be split into several variants, which have to be addressed in different ways:

  1. For mobiles, where IP constantly changes, there is no "listening" mode for the LN(P) node(s). Instead, a user would HAVE to run a full LN node on his own server - like at some "home box" or in a private cloud like the one provided by @nodl. At @MyCitadel we will be providing both of that options for LNP Node.
  2. For hosts which are behind NAT, a special NAT traversal have to be used. While I am very interested in UDP hole punching, I still haven't a chance to do an implementation for it. So for now there are two main options:
    • expose a node as a Tor hidden service - and with https://github.com/Cyphernet-DAO/rust-cyphernet the LNP Node will get full tor support in the next release (v0.10)
    • use Bifrost network to "holepunch" NAT: if your local-behind-NAT node has a connection/channels with any other node a node interested in connecting your node can send a "RPC message" using sphinx routing specifying its IP address (or using an intermediary, if both nodes are behind NAT). It's like Tor Rendezvous protocol but over LN, without Tor :) BOLT-based LN nodes can't do that, but Bifrost can

Yes, we need to look what else can be added to LNP-BP invoices to get all of those options supported.