Clarifying 6 Misconceptions About Bitcoin's Lightning Network

Author: Viktor Bunin, Coinbase Cloud Protocol Expert Compiler: Qianwen, ChainCatcher

I haven't used Lightening (later called "Lightning Network") for a while.

The last time I spent time working on it was in 2019 when I teamed up with Elizabeth Stark and other community leaders to organize the first Lightning Network Conference in Berlin. Since then, I've spent most of my time working on other protocols, and while I'm still friends with people like Elizabeth, my understanding of how the Lightning Network actually works has degraded. After re-examining, I realized that it wasn't just me, but most of my friends as well.

This post is for those who haven't used the Lightning Network recently. It will discuss misconceptions I or others I have seen. If I've missed any good points, please drop me a line on Twitter.

**Misconception 1: You must run your own node to use the Lightning Network uncustodially, which prevents ordinary users from using mobile devices. **

This was true a few years ago, but now users can use the Lightning Network on mobile devices through unmanaged light clients. Users are always in control of their keys, and the wallet experience with the Lightning Light Client is the same as calling Alchemy or Infura via RPC when using Ethereum.

**Misconception 2: The sender and receiver must be online at the same time for Lightning payments to succeed (no offline/synchronous payments). **

This situation still exists, but with some neat workarounds. Non-custodial Lightning mobile wallets can receive payments via background tasks or phone notifications even when the wallet is not running in the foreground. However, this approach is limited by mobile operating systems. Modern operating systems limit the amount of computation done by background apps to save battery. Receiving a few LN payments is fine, but if too many are received in a short period of time, they start to expire due to computational constraints.

In the longer term, the Lightning Network protocol developers are working on the Async Payments specification, which will enable arbitrarily long trustless latencies. Essentially, the payment is credited from the sender's node, but if the receiver's node goes offline, the payment stays in the sender's LSP (Lightning Network/Liquidity Service Provider, usually run by the wallet itself), until the receiver comes back online. ** This upgrade is expected to happen next year, but there is no official launch date yet. **However, this requires participating wallets to contain LSP, which may hinder its adoption as a network-wide solution.

**Misunderstanding 3: Lightning Network requires both users to invest the same amount of BTC in the channel to open the channel. **

This does not hold true. On most Lightning Network clients, the channel is open one-way by default, so only the sender needs to invest funds in the channel, and the payee can be a brand new empty address. This misunderstanding stems from the Lightning Network white paper, where examples consistently refer to two-way funding channels.

It's actually based on an interesting backstory. The earliest payment channel (Spilman) only allowed one-way payments. The innovation of the Lightning Network lies in the realization of double funds and two-way payment, and the channel has no expiration time. This is perhaps why the Lightning Network paper focuses so much on it. This was a significant invention relative to known protocol designs at the time.

**Myth 4: The Lightning Network requires users to specify specific, single-purpose invoices, which is a terrible user experience. **

This was indeed true in the beginning. But now with the Lightning Network address, it's basically the ENS of the Lightning Network. They are enabled by lnurl-pay, which allows users to send BTC to viktor@example.com via the Lightning Network, regardless of the amount and duration.

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

It must have been so before. But it's different now. Now, they have a unified QR code that neatly bundles the on-chain address with the Lightning Network invoice so that the sending wallet can choose the correct route. Open CashApp, go to Bitcoin tab. Note that while Cash App supports Lightning Network, there is no option to select Lightning Network. This is because they are using the unified QR code.

However, this doesn't solve the problem of a single balance - a user's BTC balance could still be split on-chain and into the Lightning Network. This problem can be solved to some extent through Submarineswap and/or Splicing, but my long-term view is that users will not even realize that this is a problem, nor will they realize that the Lightning Network exists because the wallet and other vendors handle the underlying complexities that will be hidden beneath a smooth user experience.

**Myth #6: The Lightning Network is capital inefficient and therefore not viable. **

This discussion is a delicate one, and I'll try to be as neutral as possible.

The Lightning Network uses a hub-and-spoke model. The hub-to-hub portion of the network is highly capital efficient due to the high “capital allocation per unit” ratio of large channels between exchanges, custodial wallets, LSPs, and optimal routing nodes.

However, where the capital inefficiency of the Lightning network is at the edges - non-custodial users. For custodial Lightning users, wallets only need to maintain large channels with other hubs and perform internal accounting of user balances. For non-custodial users, the wallet must maintain a separate open funding channel with each user. The challenge is how to maintain continuous liquidity allocation and management across these channels.

To give a concrete example: A non-custodial wallet user wants to send 0.1 BTC to a friend via the Lightning Network. Assuming there is sufficient liquidity in the channel between them and the wallet provider and every node along the way, the payment will be successful. But now the wallet has a problem - they have 0.1 BTC in the channel on their side, if the user does not receive any payment (thus rebalancing the channel), this 0.1 BTC will be idle there, causing wallet provider inefficiency low. At this point, wallet providers must decide whether to preserve liquidity, or withdraw liquidity by closing channels (which creates a poor user experience) or splicing channels (which are invisible to users).

For non-custodial users, this marginal capital inefficiency problem is a very annoying optimization problem, which is objectively worse than the account-based model regardless of the size of the transaction. However, this is not an insoluble problem. As long as it is not impossible, it must 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 costs associated with channel and liquidity management, as every splicing, channel closing, etc. requires an on-chain transaction. Bitcoin's security budget relies on a massive increase in transaction fees, but if transaction fees rise to $30-$60, channel management will be prohibitively costly at scale, and the uncustodial Lightning Network may not be available to a large portion of the global population. Hosted Lightning wallets currently have an advantage due to the incentives built in, and will likely grow even more as on-chain fees grow, as their omnibus account model makes channel management much less frequent. The community is working hard to fix this and ensure non-custodial Lightning wallets continue to be first-class citizens on the network, but there is no clear solution yet.

Lightning Network still has a long way to go to be simple, seamless and completely abstracted. There are still many edge cases, and unmanaged users have not yet enjoyed the ultimate user experience. However, many problems have already been solved, and many more will be solved in the next few years. Now that the lightning has come, can the thunder be far behind?