Do the sender and receiver need to be online at the same time? Low capital efficiency? Dispelling six misunderstandings about the Lightning Network.

Do sender and receiver need to be online simultaneously? Low capital efficiency? Debunking six Lightning Network misconceptions.

Author: Viktor Bunin, Coinbase Cloud Protocol Expert; Translation: Qianwen, ChainCatcher

It’s been a while since I used Lightning Network.

The last time I spent time studying it was in 2019 when I worked with Elizabeth Stark and other community leaders to organize the first Lightning Network Conference in Berlin. Since then, I have spent most of my time on other protocols, and although I am still friends with Elizabeth and others, my understanding of how Lightning Network actually works has deteriorated. Upon reexamination, I found that it is not just me, but most of my friends as well.

This article is prepared for those who haven’t used Lightning Network recently. It will discuss misconceptions that I or others have seen. If I miss any valuable insights, please leave me a message on Twitter.

• TG BOT Rising Upstarts in Blockchain Marketing and Grassroots Counterattack, Security Issues Await Resolution
• 10 Steps to Enhance Encryption Security
• Looking back at Yuga Labs over the past year, is APE still a good bear market bargain?

Misconception 1: Running your own node is necessary to use Lightning Network in a non-custodial way, making it inaccessible for ordinary users on mobile devices.

A few years ago, this was true, but now users can use Lightning Network on mobile devices through non-custodial light clients. Users always have control over their own keys, and the wallet experience using a Lightning Network light client is similar to using an Ethereum wallet with RPC calls to Alchemy or Infura.

Misconception 2: Both the sender and the receiver must be online at the same time for a Lightning Network payment to succeed (no offline/sync payments).

This situation still exists, but there are some clever workarounds. Even if the wallet is not running in the foreground, non-custodial Lightning Network mobile wallets can receive payments through background tasks or mobile notifications. However, this method is limited by the mobile operating system. Modern operating systems limit the computational load of background applications to save battery. Receiving a few LN payments is not a problem, but if too many are received within a short period of time, they will start to fail due to computational limitations.

In the long run, Lightning Network protocol developers are working on developing the Async Payments specification, which will enable arbitrary-length trustless delays. Essentially, the payment will be recorded by the sender’s node, but if the receiver’s node is offline, the payment will stay in the sender’s LSP (Lightning Network/Liquidity Service Provider, typically operated by the wallet itself) until the receiver comes back online. This upgrade is expected to take place next year, but there is currently no official release date. However, it requires participating wallets to include LSP, which may hinder its adoption as a network-wide solution.

Misconception 3: Lightning Network requires both users in a channel to lock the same amount of BTC to open the channel.

This is not true. In most Lightning Network clients, the channels are by default unidirectional, so only the sender needs to lock funds into the channel, and the recipient can be a completely new empty address. This misconception stems from the Lightning Network whitepaper, where examples always mention bidirectional funding channels.

It is actually based on an interesting backstory. The earliest payment channels (Spilman) only allowed unidirectional payments. The innovation of Lightning Network is the realization of bidirectional funding and bidirectional payments without channel expiration. This is perhaps why the Lightning Network whitepaper pays so much attention to it. It was a significant invention compared to the known protocol designs at the time.

Misconception 4: The Lightning Network requires users to specify specific, single-purpose invoices, which results in a very poor user experience.

Initially, this was indeed the case. But now with Lightning Network addresses, they are essentially the ENS (Ethereum Name Service) of the Lightning Network. They are enabled by lnurl-LianGuaiy, allowing users to send BTC to [email protected] via the Lightning Network, regardless of the amount or duration.

Misconception 5: Users need to understand and choose between Bitcoin and the Lightning Network when sending BTC.

That was definitely the case in the past. But things have changed now. Users now have unified QR codes that cleverly bundle on-chain addresses and Lightning Network invoices together, allowing the sending wallet to choose the correct path. Open the CashApp and go to the Bitcoin tab. Please note that although CashApp supports the Lightning Network, there is no option to choose the Lightning Network. This is because they are using unified QR codes.

However, this does not solve the issue of a single balance – the user’s BTC balance can still be split between on-chain and Lightning Network. This problem can be addressed to some extent through Submarine Swaps and/or Splicing. But my long-term view is that users won’t even be aware that this is a problem, nor will they be aware of the existence of the Lightning Network, as wallets and other providers will handle the underlying complexity, hiding these issues behind a smooth user experience.

Misconception 6: The Lightning Network is inefficient in terms of capital, making it impractical.

This discussion can be quite nuanced, and I will try to remain neutral.

The Lightning Network adopts a hub-and-spoke model. The large channels between exchanges, custodial wallets, LSPs, and the best routing nodes have a high “unit capital allocation” ratio, resulting in high capital efficiency in the hub-to-hub portion of the network.

However, the Lightning Network’s capital efficiency is low at the edge – for non-custodial users. For custodial Lightning Network users, the wallet only needs to maintain large channels with other hubs and internally account for user balances. For non-custodial users, the wallet must maintain separate open funding channels with each user. The challenge lies in how to maintain continuous liquidity allocation and management between these channels.

Here’s a specific example: A non-custodial wallet user wants to send 0.1 BTC to a friend via the Lightning Network. Assuming they have sufficient liquidity in the channel with the wallet provider and each node along the way, the payment will be successful. But now the wallet encounters a problem – their party has 0.1 BTC in the channel, and if the user does not receive any payment (thus rebalancing the channel), this 0.1 BTC will be idle there, resulting in low efficiency for the wallet provider. At this point, the wallet provider must decide whether to retain liquidity or extract liquidity by closing the channel (which would result in a poor user experience) or splicing the channel (which the user cannot see).

For non-custodial users, this issue of low capital efficiency at the edge is a very frustrating optimization problem and objectively worse than an account-based model, regardless of the transaction scale. However, this is not an unsolvable problem. As long as it’s not impractical, it can be successful, which is also the motto of the Bitcoin developer community.

In addition to the difficulty of capital optimization, another challenge comes from the cost associated with channel and liquidity management, as each operation such as splicing and channel closure requires on-chain transactions. The security budget of Bitcoin relies on a significant increase in transaction fees, but if the transaction fees rise to $30 to $60, the cost of channel management will be extremely expensive, and the majority of the global population may not be able to use non-custodial Lightning Network. Due to the establishment of incentive mechanisms, custodial Lightning Network wallets currently have an advantage, and with the increase in on-chain fees, their advantage may become even greater, as their omnibus account model greatly reduces the frequency of channel management. The community is working hard to solve this problem and ensure that non-custodial Lightning Network wallets continue to be first-class citizens on the network, but there is currently no clear solution.

To achieve simplicity, seamlessness, and complete abstraction, the Lightning Network still has a long way to go. Currently, there are still many edge cases where non-custodial users have not enjoyed the ultimate user experience. However, many problems have already been solved, and more problems will be solved in the coming years. Now that the lightning has arrived, will the thunder be far behind?

We will continue to update Blocking; if you have any questions or suggestions, please contact us!