Translation of Cezary Dziemian’s article by Bartlomiej (Tony) Sanak from the source:

http://lightningnetwork.pl/2019/07/15/dlaczego-ln-nie-dziala-blyskawicznie

Lightning Network (as the name suggest) was designed for lightning-fast transactions. There was even the idea of micropayments, for consuming content like 1 second period of video watch time. Unfortunately, real life is far from theory and LN payments aren’t always as fast. Usually you have to wait more than a second, and even a few dozen seconds in some corner cases. I am a bit disappointed by it and probably I am not alone. 2–3 seconds is a tough pill to swallow, but bearable. Everything more than that just too slow. And we are speaking about the network state with “only” 30k channels. How will it look like when this number goes up 10x to 300k channels? Will LN become useless? I’d like to share my thoughts about this topic.

Why is it so slow?

Where does the difference in transaction time come from? Why sometimes it’s about 2 seconds and sometimes half a minute? Lightning Network payments work in a loop. When the wallet knows the transaction receiver and transaction amount, it starts searching for the optimal path to the receiver. But in LN there is always a small chance that the payment will fail. Maybe one of the nodes could go offline during the payment? Or the channel balance on the path changes and blocks the payment from goingthrough. If the payment won’t go through, the wallet will find the cause and in the next step it will try to find better route omitting the problematic node or channel. And so on.

So the circle of path discovery and payment attempts is going on. In the case of LND, the most popular LN implementation, every path discovery takes around 2 seconds (30k channels). I haven’t timed the payment attempt, but it’s much faster. So if the wallet is able to find the path in the first iteration, it’s 2 seconds, second one — 4 seconds and so on.

Suspiciously long 2 seconds…

As I mentioned in the LND implementation, single path discovery takes around 2 seconds on the consumer-grade hardware. I am not aware of the details of the LND algorithm but it is so slow! Annoyed by the state of the current algorithm, I’ve started my own effort of creating a path-discovery algorithm for lightning network. My algorithm finds the path in around 6ms, and when the route is really long and complicated it’s up to 80ms. It’s few hundred times faster than the LND algorithm! Does it mean that LND is garbage and my version should be immediately implemented on a large scale? Not so fast…

My algorithm is untested and it has some issues.

From my observations, LND prioritizes the transaction’s cost over other parameters. It tries to find the cheapest route possible. In my implementation the transaction’s cost is just one of few parameters and it’s not so heavily prioritize. There is a ton of comments about how the lightning network isn’t really that fast, contrary to comments about cost, haven’t found a single complaint about why transaction cost 3 sat when it could cost 1! So when default LND path-discovery bets on minimizing the fee, my algorithm prioritizes the fastest path-discovery and highest success-rate for payments. It definitely prioritizes high-capacity channels. The bigger the channel volume, the more chances that the payment will go through. The downside of this ideology is that it may favorize the big channels which may lead to network centralization.

I don’t think I will publish this algorithm, it’s just an experiment. But it would be some sort of proof for possible enhancements of LN. Moreover, the path-discovery algorithm can be an individual matter and there is a high incentive for the existence of many, competing solutions. Lightning Network has a big advantage over blockchain in this area. For example, Bitcoin’s blocks are mined on average every 10 minutes which derives from consensus rules. The attempt to make it 5 minutes, would require the acceptance of most of the network members. It’s extremely problematic and rather unreal. In Lightning Network the speed can be achieved on the wallet level. So I suspect a lot of competition in this area, and I am sure the algorithms will be better and faster.

Why LND developers can’t focus on this problem? Right at this moment, on LND github repo there are more than 200 open “issues”, that means errors, bugs and enhancement proposals suggested by users. LND devs are extremely busy. But the path-finding algorithm is starting becoming an issue to the users, so I anticipate some major upgrades in the near future.

Shitchannels

Equally important (or even more important) is the payment channels quality. Right now in LN we have a lot of channels that I could’ve called as “shitchannels”. Experimental channels, low volume ones, usually with the balance over one side. In case of this type of channels the whole payment process is prolonged. It often happens that after finding the best path, there are some channels on the way that are very “stale”. The owner set them up in the past and isn’t taking care of them anymore, so they are unbalanced. So how the channels should be created in a good way?

No more small channels!

Small channels for sending/receiving payments can be created as private channels. Public channels should be used mostly for payment routing and should have a rather high volume. The nodes are sharing the channel information between themselves. In my opinion, they shouldn’t advertise some channels, for example those under 0.01 BTC of volume.

Sturdy nodes

If some entity wants to provide the “service” of channel routing, it must no only consider the channel volume but also the node stability. The node should be set up on high-end hardware, hopefully secured for DDOS attacks, with high bandwidth and low latency, and UPS. In short, the node owner should be motivated, to have its node always ready when someone decides to use it for routing. Here comes the simple mechanism, already implemented. When the specific node goes down, it becomes unable to route transactions for some period of time (by the wallet). Our wallet can store the blacklist that didn’t complete the transactions in a proper manner. It may try not to use them eg. for the following week after the mishap. This simple mechanism could put pressure on node owners, for them to just work properly and always.

Balanced Channels

Our wallet knows the summary of the volume of every public channel. What it doesn’t know is their balance — the amount of funds on either side of the channel. The wallets look up the path based on the volume, it doesn’t guarantee that payment will go through.

Since a while, the channel creator can decide the max amount to route using the channel. I imagine that in future if someone will create a 0.2 BTC channel, he/she can allow only route the payments up to 0.01 BTC. After creation it will wait for the channel to balance in a way to have roughly 0.1BTC on each side. Using this trick the owner can allow for immediate routing of a few payments in a row. After 5 payments 0.01BTC each in the same direction, the balance will be 0.5 BTC in this direction and 0.15 BTC in the opposite one. The situation is getting “dangerous” as 5 more payments in the wrong direction and this direction will become illiquid. After this dark scenario will come to life, the node won’t be able to route any more payments in this direction, and wallets that will try to use it (unsuccessfully) will add it to blacklist for a week. The best scenario is to make the channel balanced to roughly 0.1 BTC on each side. Node operator can “hack” the network by sending special payment to himself. Sending this payment to himself, the node operator can balance two of his channels at once. Another option is to use the submarine swap. Submarine swap is the payment type in which the peer sending some amount of BTC (in LN) and in return the peer receives some on-chain funds.

Summary

I mentioned 5 issues to fix in current LN schema and operation. It is basically a path-finding algorithm and 4 aspects of successful payment routing. I think these aspects will be fixed and the total time of payment transfer will go down (even if the number of channels and nodes will rise).

Author: Cezary Dziemian — http://lightningnetwork.pl/

Translation: Bartlomiej (Tony) Sanak — https://twitter.com/explorecryptony