LN Challenges & Moderated Node Pool Solution
LN has a current challenge of liquidity. It’s highly likely that capital isn’t allocated optimally for the flows happening in the network. The network probably has many unbalanced channels, even though the participants are trying their best to set the fees and perform channel management all individually. But not only is this extremely time-consuming and a lot of work, but it’s largely a guessing game. And it leads to a lot of overall inefficiency in terms of deployed capital on the network. There’s thousands of BTC just sitting around “stuck” and it’s hard to rebalance them because circular rebalancing often leads to other nodes getting skewed, as well as the expensive costs of on-chain efforts of closing and reopening channels to try to regain balance.
But what if we could collectively, and voluntarily, manage liquidity in a way that takes the effort away from individual liquidity management?
Lightning Network Moderated Pools
A lightning network moderated pool is where a moderating node sets up rules for it’s participating members.
The moderator keeps track of the full view of the member nodes channel balances (not real-time), and ensures that the deployed capital is healthy and optimal.
As balances begin to skew, the moderator initiates either intra-LN rebalancing transactions or peer liquidity swaps using Liquid BTC. If the intra-LN rebalancing is cheaper and available, it will prefer that. Otherwise, it will request the nodes to use Liquid BTC to rebalance the network. The moderator only sends the command to do this to the nodes, and the nodes themselves need to execute it securely. The peer could reject the request, but then the peer is considered “misbehaving” and could be rejected from the pool.
The moderator receives the channel balances from all the nodes every hour. This can be tweaked based on flow and how rapidly the balances are being skewed. Larger channels are also ideal to reduce the reporting time.
A participating node also reports the available Liquid BTC it has for the purposes of rebalancing. Also, the moderator sets the fees of all the channels based on the flow in and out of the network itself. It will do this dynamically to ensure traffic flows properly to replenish routes that are skewed. The pool will also distribute the fees evenly so that all participants can aim to receive the best amount possible.
With these 3 tools (intra-LN rebalances, peer swap rebalances, and route fee rebalancing) the pool gains the ability to remain balanced.
Transactions happening within the pool will likely be optimized to succeed all the time. For transactions going outside of the pool to others, the likelihood will decrease unless the others are also being managed properly.
A marketplace of different pools can develop, based on how well they are managed, and the rules they require for membership. Typical rules will be the amount of BTC they have for opening channels, the amount of LBTC they have for maintaining peer liquidity swaps, and the history of the node if it’s not new.
The moderator can allow for nodes to connect outside of the pool network. These channels, however, cannot be rebalanced automatically as the other side may not be participating in peer swaps, etc. These non-pool channels are considered gateways.
The gateways into the broader LN are an important factor, as they provide visibility into the total inflow and outflow that is not part of the pool.
If the total inflow and outflow is not balanced, it will set fees higher to attempt to slow the tide. If that’s not sufficient, the pool will announce a need for new channels to be opened, and others to be closed, to support the skew. If the pool is large enough, this shouldn’t be necessary. However, if funds are flowing all towards say “Giant Exchange X” and funds never come back from it, and keeping fees high doesn’t maintain any possible flow, then the pool will have the inbound 99% full channels be closed to regain BTC, and brand new 99% full channels to be opened towards the “Giant Exchange X” node.
In this way, the moderator is also managing external balance while spreading or distributing the load among all of it’s member nodes.
In the future, I envision many popular LN pools dominating the network and making it easy and seamless to join (or leave) the pool. Individual node management becomes much easier and possibly more cost-effective as well, and hopefully profitable. The moderator can also advertise the overall profitability of the pool, to entice more members to join.
I think there are a lot of people with BTC who want to run a LN node and participate in the success of Bitcoin. But also, they don’t want to make LN node management their full-time job. This automation could be the way for their contributions to be hands-free, and ultimately help grow LN to be more robust, cheaper, faster, and more efficient in the way BTC is deployed.
The other nice thing about this is we don't necessarily need gossip to communicate what is needed between each and every peer. Instead, the moderator can be a lightweight single point of contact.
reply
So the moderator has a macaroon (or equivalent) for each member node?
Seems like it has a lot of overlap with LSPs, but also depends on a trusted third party.
reply
The more I think about this, it sounds like it’s down a similar path as what Lightning Labs is doing with autopilot in Lightning Terminal, but more distributed, which is great.
Plus Liquid, which tbh sounds like an arbitrary addon. Might as well also support other out of band payments between nodes with virtual channels.
reply
Perhaps it would be some kind of very limited scope macaroon. I don't know if you could rate limit queries so they can't make more than 1 query per hour.
There is no trust needed for the third party since the moderator only broadcasts "here's my recommendation" and has no power to make any direct changes. The nodes would have to voluntarily make any changes.
Or maybe I don't understand what is being entrusted when you say trusted third party.
You're certainly not trusting access to any funds, or allowing access to any of the server/hardware.
reply
Ok, so when you say the moderator initiates rebalances and sets fees, what you mean is they make recommendations for those. It’s up to the node to cooperate, and if they’re too unreliable they get removed (from the recommendation network, and possibly have channels closed). Is that accurate?
reply
Yep, that's the idea. You don't give them any special powers, it's just a mutual agreement that is automated. Anyone is free to leave the pool at any time. The channels don't have to get closed either, they just become gateway channels from the perspective of the pool.
For peer swap or channel openings, for example, the node operator will get a notification and some reasonable time frame to complete it. But the moderator can't force the node to do anything.
reply