Do both parties need to be online at the same time? Low capital efficiency? Breaking six major misconceptions about the Lightning Network

Original Title: Lightning for those who haven't checked in on it in a while

Author: Viktor Bunin, Protocol Expert at Coinbase Cloud

Compiled by: Qianwen, ChainCatcher

I haven't used Lightning (hereafter referred to as "Lightning Network") for a while.

The last time I spent time studying it was in 2019 when I collaborated 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 while I remain friends with Elizabeth and others, my understanding of how the Lightning Network actually works has deteriorated. Upon revisiting it, I found that not only I feel this way, but most of my friends do too.

This article is for those who haven't used the Lightning Network recently. It will discuss misunderstandings I or others I have seen have. If I miss any good points, please let me know on Twitter.

Misunderstanding 1: You must run your own node to use the Lightning Network in a non-custodial way, which prevents regular users from using mobile devices.

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

Misunderstanding 2: The sender and receiver must be online simultaneously for Lightning Network payments 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 mobile operating systems. Modern operating systems restrict the computational load of background applications to save battery. Receiving a few LN payments is fine, but if too many are received in a short time, they may start to fail due to computational limits.

In the long run, Lightning Network protocol developers are working on an Async Payments specification that will enable trustless delays of arbitrary length. Essentially, payments will be credited from the sender's node, but if the receiver's node is offline, the payment will remain 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 launch date. However, this requires participating wallets to include LSP, which may hinder its adoption as a solution across the network.

Misunderstanding 3: The Lightning Network requires both users to contribute the same amount of BTC to open a channel.

This is not true. On most Lightning Network clients, channels are by default opened in a one-way manner, so only the sender needs to fund the channel, while the receiver can be a brand new empty address. This misunderstanding stems from the Lightning Network white paper, where examples consistently refer to bi-directional funding channels.

This is actually based on an interesting backstory. The earliest payment channels (Spilman) only allowed one-way payments. The innovation of the Lightning Network is that it enables dual funding and bi-directional payments, and the channels do not expire. This may be why the Lightning Network paper places such emphasis on it. It was a significant invention compared to the protocol designs known at the time.

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

This was indeed the case at first. But now there are Lightning Network addresses, which are essentially the ENS of the Lightning Network. They are enabled by lnurl-pay, allowing users to send BTC to viktor@example.com via the Lightning Network, regardless of the amount or duration.

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

This was definitely the case before. But now it is different. They now have a Unified QR Code, cleverly bundling on-chain addresses and Lightning Network invoices together, allowing the sending wallet to choose the correct path. Open CashApp and go to the Bitcoin tab. Note that while CashApp supports the Lightning Network, there is no option to select the Lightning Network. This is because they are using the Unified QR Code.

However, this does not solve the single balance issue—users' BTC balances may still be split between on-chain and the Lightning Network. This issue can be partially addressed through Submarine Swaps and/or Splicing, but my long-term view is that users may not even realize this is a problem or be aware of the existence of the Lightning Network, as wallets and other providers will handle the underlying complexity, hiding these issues beneath a smooth user experience.

Misunderstanding 6: The Lightning Network has low capital efficiency, making it unfeasible.

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

The Lightning Network adopts a hub-and-spoke model. Due to the high "unit capital allocation ratio" of large channels between exchanges, custodial wallets, LSPs, and optimal routing nodes, the hub-to-hub portion of the network has high capital efficiency.

However, the inefficiency of capital in the Lightning Network occurs at the edges—non-custodial users. For custodial Lightning Network users, wallets only need to maintain large channels with other custodians and internally account for user balances. For non-custodial users, wallets must maintain separate open funding channels with each user. The challenge lies in how to maintain ongoing liquidity allocation and management between these channels.

For example: a non-custodial wallet user wants to send 0.1 BTC via the Lightning Network to a friend. Assuming they have sufficient liquidity in the channel with the wallet provider and at each node along the way, the payment will succeed. But now the wallet faces a problem—on their side, they have 0.1 BTC in the channel, and if the user does not receive any payments (thus rebalancing the channel), this 0.1 BTC will sit idle, leading to inefficiency 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 create a poor user experience) or splicing the channel (which the user does not see).

For non-custodial users, this issue of edge capital inefficiency is a frustrating optimization problem, objectively worse than an account-based model, regardless of the transaction size. However, this is not an unsolvable problem. As long as it is not unfeasible, it can succeed, which is the motto of the Bitcoin developer community.

In addition to the difficulty of capital optimization, another challenge comes from the costs associated with channel and liquidity management, as each splicing, channel closure, etc., requires on-chain transactions. Bitcoin's security budget relies on a significant increase in transaction fees, but if transaction fees rise to $30 to $60, the scale costs of channel management will be extremely high, potentially making non-custodial Lightning Network inaccessible to much of the global population. Due to the establishment of incentive mechanisms, custodial Lightning Network wallets currently have an advantage, and as on-chain fees rise, their advantage may grow, as their omnibus account model greatly reduces the frequency of channel management. The community is working to address this issue to 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 has a long way to go. There are still many edge cases where non-custodial users do not enjoy an optimal user experience. However, many issues have been resolved, and more will be addressed in the coming years. Now that the lightning has arrived, how far can the thunder be?

Want to try Lightning?

Non-custodial users can choose Phoenix Wallet or Breez

Custodial users can choose Wallet of Satoshi

Or users can run LND manually.