Lightning Payment Speed 2022

date

Feb 17, 2022

slug

lightning-payment-speed-2022

status

Published

Intro

As a service, it is hard to choose reliable routing peers that forward payments quickly. Plenty of nodes have bad response times and do not maintain proper liquidity in their channels. This makes payments slow and payment times of 8+ seconds not uncommon. Recent tests by c-lightning revealed a median payment time of 8.6s baseline. And no, this is not a unique c-lightning issue.

In this article, we show how path finding in the Lightning Network works and how LnRouter models the average payment speed of a node to create its Routing Score. At the end, we give tips on how to improve your payment speed as a service.

How Path Finding Works In Context Of Time

We use this example throughout the article. A service is connected to a routing node that is itself connected to several peers. Some channels have enough liquidity (✔️) to send a payment, some don't (❌). Every channel has its own response time in seconds.

For this examples sake, we do not consider channel size, fees, probabilistic path finding or mission control to select paths.

Image 1: The graph our example is based on.

The service sends a payment to the target node. It therefore probes several routes. Every payment attempt can fail due to liquidity issues. Depending on the channels used, the attempt takes more or less time.

First Attempt

The service sends a payment attempt that spans 3 channels to reach the target node. Because the channel between the routing node and Peer1 doesn't have enough liquidity, this first payment attempt fails at the routing node.

This attempt took 0.3 seconds to fail. Service → 0.3s → Routing Node 🚫

After this first attempt, the service tries a second route to send the payment.

Second Attempt

This second payment attempt came closer to the target but failed nonetheless due to liquidity issues at Peer2.

This attempt took 1.8s seconds to fail. Service → 0.3s → Routing Node → 1.5s → Peer2 🚫

Third Attempt

The service makes another payment attempt that finally succeeds. All channels on this path have enough liquidity to forward the payment.

This attempt took 1.1s seconds to succeed. Service → 0.3s → Routing Node → 0.5s → Peer3 → 0.3s → Target ✅

All in all, the 3 payment attempts and therefore the payment took

Attempt: 0.3s

Attempt: 1.8s

Attempt: 1.1s

= 3.4s to complete.

Learnings

#1 Due to the way Lightning payments work, liquidity matters for payment speed. Failed payment attempts can significantly delay the payment. In our example, the successful payment attempt only took 1.1s. But due to lacking liquidity, it took 3.4s.

#2 The response time of your directly connected peers matters a lot. These channels get used first and therefore the most during path finding and have a disproportionate high impact on your payment speed. Let's assume the channel between the service and the routing node has a response time of 4s. Because this channel is passed for every payment attempt, the final payment time would be 14.3s instead of 3.4s. This is a significantly worse payment experience.

Routing Score Models Payment Speed

The routing score answers one question in a single number:

How fast can this node forward a payment to all other nodes in the network?

LnRouter measures the following metrics to determine the routing nodes score.

% of liquid channels is the relative amount of channels that have sufficient funds on both sides and are therefore balanced. Example value: 66%

HTLC response time is the response time you get when a node forwards a payment to its peer. Example value 0.3s

Centrality is a metric on how well your node is connected to the rest of the graph.

Latency (HTLC response time) in general, has been mentioned by Lightning developers to be a core metric. Don’t be surprised in case latency directly or indirectly shows up in path finding cost functions at some point. Physical channel distances could be a great proxy latency.

With this information, LnRouter then models the average payment speed that a routing node can provide. It then takes all nodes and ranks them between 0 and 100. The higher the score the better.

Image 6: LnRouter Routing Score & Metrics

Median Network Numbers

Here are some LnRouter metric ranges. Be aware that LnRouter excludes nodes with bad response time and low channel count. Therefore these numbers are better than the network average.

Conclusion

After all this theory on what is a good and a bad routing node, what is the best way to achieve fast Lightning payments as a service?

🛠

Only open channels to nodes with a LnRouter Routing Score of 75+. The Routing Score models payment speed directly.

Depending on your available liquidity, you can be even more strict and only allow nodes with even higher scores.

The upcoming LnRouter Channel Recommender (~18th Feb 2022) is the perfect way to build a powerful service/merchant node that delivers payments fast and successfully.

If you are a service and are interested in

Lightning Network consultancy

Optimizing your node

then reach out to me on severin@lnrouter.app.

In the future we will see path finding algorithms that optimise for high payment speed next to low fees. Until then, the LnRouter Routing Score is the best solution.

A big thanks to Rene Pickhardt for the helpful discussions around this topic.

Severin