One of the fundamental limitations of the Lightning protocol is the way payment routing is handled and performed. It is completely source-driven, meaning that the sender of a payment is the one who constructs the entire path from themselves to the recipient to facilitate the payment. This poses a problem when it comes to channels’ changing balances over time, as they route payments between numerous different users across the network. Once a sender “locks” and chooses a specific route, that route cannot be changed until an outage occurs. The message returns to the sender, allowing them to construct a completely new route around the point where the first attempt failed.
This requires either dealing with a cumbersome and annoying UX, or using payment research, where you deliberately make payments that you will fail on purpose, just to see if the route you want to use will work before trying again with the actual payment. The former is just a bad user experience and not what you want if you’re trying to make something that’s a viable payment solution for people at scale, and the latter puts an unnecessary burden on the network as a whole as routing nodes have to interact with the network. traffic and liquidity complications of constant payments made with no intention of completing them just to test the viability of a route.
The ultimate cause of these problems is a route’s inability to change its interim payment without sender intervention. Because the entire payment process is onion encrypted, this is not really possible. Each hop is only aware of the hop before it and the hop after it. They have no knowledge of the final destination allowing them to construct an alternate route from them to the recipient.
While this is a huge barrier to switching from source-based routing, it doesn’t prevent it altogether. Although as an intermediate node you cannot completely reconstruct a new route from yourself to the destination, you can redirect payment from yourself to the next hop defined in the path chosen by the sender. So if Bob receives a payment that he needs to route to Carol, and the channel he needs to route it through doesn’t have the capacity needed to route it, he can send what he can through that channel and the rest of the route payment. he can find the payment amount via other routes from himself to Carol.
Last month, Gijs van Dam wrote a proof of concept plugin for CLN (available here) that does just that, building on multi-path payments that allow a payment to be split and follow multiple routes to the recipient. If Bob and Carol are both using the plugin, they can, in the right situations, communicate to each other that a payment being routed through one channel is actually being partially redirected, so that Carol doesn’t immediately drop it when she sees what she’s doing . sent is less than what it is supposed to transmit. This way, if alternative routes are available between Bob and Carol when the route determined by the sender is not feasible, they can simply reroute the necessary amount and the payment can succeed without having to fail completely, sending it back to the sender and be redirected by them.
If widely adopted as a standardized behavior across the network, it could have a huge positive impact on payment success rates, dramatically improving the UX of Lightning users looking for a simple payment mechanism that just works. It’s an incredibly simple and logical behavior that could significantly improve a known flaw. However, that’s not all it can do.
One of the main reasons Gijs van Dam became interested in tackling this problem actually has nothing to do with simply improving payment success and UX for users, it was actually because of a privacy shortcoming. One of the known privacy issues that Lightning is vulnerable to is channel probing, this is the issue that Gijs was concerned about.
As I mentioned above, it is used by some wallets to ensure that a payment is successful before the actual payment is actually attempted, but this technique can also be used to determine the distribution of funds between both sides of a channel. If this is done repeatedly and in carefully chosen amounts, the success and failure of each research effort can reveal how the money is distributed on both sides of the channel. Taken even further and executed systematically and on a regular basis across numerous channels, this technique can even deanonymize payments by effectively watching in real time how balances change between channels.
Lightning is constantly portrayed as a privacy tool for transactional use, but reality shows that techniques such as channel privacy probing can be weak at best in many cases without a user being sophisticated in how they interact with the network. One of the interesting side effects of payment splitting and switching is that it undermines intrusive attacks. The reason a probing attack works is because you can keep probing different amounts until a payment fails. If done correctly, this will give you a very small range between the last successful payment attempt and the failed one, namely the channel balance distribution.
In a world where Lightning nodes can redirect payments from components that would otherwise fail so that they succeed, the inherent assumption that examining channel balance relies on is completely broken. That your payment attempt will fail when the specific channel you want to go through does not have the liquidity to forward it. With payment splitting and switching, this assumption is no longer true, and the more nodes on the network support switching, the more error-prone this assumption becomes (up to 62% according to a simulation using real-world Lightning network data from Gijs).
So not only is this proposal relatively simple, it not only provides a way to improve the success rate of payment attempts, it also helps address one of the Lightning Network’s biggest privacy shortcomings. I think this proposal, especially in the wake of the recent Lightning vulnerability, shows that while Lightning is not without its problems, they are not impossible to fix or mitigate. In fact, it will be very common for solutions to one problem to help with another problem.
Rome wasn’t built in a day, and solutions that actually preserve Bitcoin’s core properties in a scalable and sustainable way won’t be either.