About the Six Misunderstandings of Lightning Network
Original title: Lightning for those who haven’t checked in on it in a while
Original author: Viktor Bunin, Coinbase Cloud Protocol Specialist
Translated by: Qianwen, ChainCatcher
It's been a while since I used Lightning.
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've spent most of my time on other protocols, and although I'm still friends with Elizabeth and others, my understanding of how the Lightning Network actually works has deteriorated. Upon revisiting it, I found that not only was I in this situation, but most of my friends were as well.
This article is for those who haven't used the Lightning Network recently. It will address misconceptions that I or others have encountered. If I miss any good points, please leave me a message on Twitter.
Misconception 1: You must run your own node to use the Lightning Network in a non-custodial manner, which prevents regular users from using it on mobile devices.
This was true a few years ago, but now users can use the Lightning Network on mobile devices through non-custodial light clients. Users always have control of their own keys, and the wallet experience using a Lightning Network light client is the same as using a wallet through RPC calls to Alchemy or Infura when using Ethereum.
Misconception 2: Both the sender and receiver must be online 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, a non-custodial Lightning Network mobile wallet can receive payments through background tasks or mobile notifications. However, this method is subject to limitations imposed by mobile operating systems. Modern operating systems restrict the computational power of background applications to save battery. Receiving a few LN payments is no problem, but if too many are received within a short period of time, they may start to fail due to computational limitations.
Misconception 3: Lightning Network requires both parties to deposit the same amount of BTC to open a channel.
This is not true. In most Lightning Network clients, channels are by default unidirectional, so only the sender needs to deposit funds into the channel, and the recipient can be a brand new empty address. This misconception arises from the Lightning Network whitepaper, where examples consistently mention bidirectional funding channels.
This actually stems from an interesting backstory. The earliest payment channels (Spilman) only allowed unidirectional payments. The innovation of Lightning Network lies in achieving bidirectional funding and payments without an expiration time for the channels. Perhaps this is why the Lightning Network paper emphasized it so much. It was a significant invention compared to the known protocol designs at that time.
Misconception 4: Lightning Network requires users to specify specific, single-purpose invoices, which leads to a terrible user experience.
This was indeed true initially. But now, with Lightning Network addresses, they are essentially the ENS (Ethereum Name Service) of 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.
Misconception 5: Users need to understand and choose between Bitcoin and the Lightning Network when sending BTC.
That was definitely the case before. But now, things have changed. Now, they have BitcoinQR
Unified QR Code, cleverly bundling on-chain addresses and Lightning Network invoices together, so that sending wallets can choose the correct path. Open CashApp and go to the Bitcoin tab. Please note that while Cash App supports the Lightning Network, there is no option to choose the Lightning Network. This is because they are using the Unified QR Code.
However, this does not solve the problem of a single balance - a user's BTC balance may still be split between the on-chain and Lightning Network. This problem can be partially solved through Submarine swaps and/or splicing, but my long-term view is that users will not even be aware that this is a problem or that the Lightning Network exists, as wallets and other providers will handle the underlying complexity, with these issues hidden beneath a smooth user experience.
Misconception 6: The Lightning Network is capital inefficient and therefore impractical.
This discussion can be quite nuanced, and I will try to remain neutral.
The Lightning Network follows a hub and spoke model. The hub-to-hub portion of the network, consisting of major exchanges, custodial wallets, LSPs, and the best routing nodes, has high capital efficiency due to the large channels with high "unit capital allocation" ratios.
However, the Lightning Network's capital efficiency is low at the edges - for non-custodial users. For custodial Lightning Network users, wallets only need to maintain large channels with other centers 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 continuous liquidity distribution and management between these channels.
To give 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 between them and the wallet provider, as well as every node along the route, the payment will succeed. But now the wallet encounters a problem - they have 0.1 BTC in their side of the channel, and if the user does not receive any payment (thus rebalancing the channel), this 0.1 BTC will sit idle there, causing inefficiency for the wallet provider. In this case, the wallet provider must decide between retaining liquidity or extracting it by closing the channel (resulting in a poor user experience) or splicing the channel (invisible to the user).
For non-custodial users, the inefficiency of edge capital is a frustrating optimization problem. Objectively, regardless of the size of the transaction, this is worse than an account-based model. However, this is not an unsolvable problem. As long as it is not infeasible, success is certain, 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 operation such as splicing and channel closure 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 cost of channel management will be extremely high, and most of the world's 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 significantly reduces the frequency of channel management. The community is working hard to solve this problem, ensuring 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. 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 will be solved in the coming years. Since the lightning has arrived, will the thunder be far behind?
Want to try Lightning?
Non-custodial users can choose Phoenix Wallet or Breez
Custodial users can choose Wallet of Satoshi
Alternatively, users can run LND manually
