Lightning Network has made significant improvements compared to previous years, but there is still a long way to go to achieve simplicity, seamlessness, and complete abstraction.
Original Title: Lightning for those who haven’t checked in on it in a while
Author: Viktor Bunin, Coinbase Cloud Protocol Expert
Translation: Qianwen, ChainCatcher
- The Rising TG BOT On-Chain Marketing and Grassroots Counterattack Carnival, Security Issues Await Resolution.
- The ambition behind stablecoins 400 million potential crypto users holding $600 million worth of cryptocurrencies.
- LianGuaiyLianGuail launches USD stablecoin PYUSD
I haven’t used 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, although I am still friends with Elizabeth and others, my understanding of how Lightning Network actually works has degraded. Upon reexamination, I found that not only was this the case for me, but also for most of my friends.
This article is prepared for those who have not recently used Lightning Network. It will discuss misconceptions that I or others have observed. If I have missed any good points, please leave me a message on Twitter.
Misconception 1: It is necessary to run your own node to use Lightning Network in a non-custodial manner, which makes it inaccessible for regular users on mobile devices.
This was true a few years ago, but now users can use Lightning Network on mobile devices through non-custodial light clients. Users always have control of their own keys, and the wallet experience using Lightning Network light clients is similar to using Ethereum wallets by making RPC calls to Alchemy or Infura.
Misconception 2: Both the sender and receiver must be online at the same time for Lightning Network payments to be successful (no offline/synchronous 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 power of background applications to save battery. Receiving a few LN payments is not a problem, but if too many are received in a short period of time, they will start to fail due to computational limitations.
In the long run, Lightning Network protocol developers are developing an Async Payments specification, which will enable arbitrary-length trustless delays. Essentially, payments will be credited from 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 solution for the entire network.
Misconception 3: Lightning Network requires both users in a channel to invest the same amount of BTC to open the channel.
This is not true. In most Lightning Network clients, channels are by default unidirectional, so only the sender needs to fund the channel, and the recipient can be a completely new empty address. This misconception stems from the Lightning Network whitepaper, which has always mentioned examples of bidirectional payment channels.
This is actually based on an interesting background story. The earliest payment channel (Spilman) only allowed one-way payments. The innovation of the Lightning Network is the realization of dual funding, bidirectional payments, and channels without expiration dates. This may be the reason why the Lightning Network paper pays so much attention to it. Compared to the known protocol designs at the time, this is a major invention.
Misunderstanding 4: The Lightning Network requires users to specify specific, single-purpose invoices, which is a very bad user experience.
At the beginning, this was indeed the case. But now with Lightning Network addresses, it is basically the ENS of the Lightning Network. They are enabled by lnurl-LianGuaiy, 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.
It used to be like this for sure. But now it’s different. Now they have a unified QR code that cleverly bundles on-chain addresses and Lightning Network invoices together, so the sending wallet can choose the correct path. Open CashApp and go to the Bitcoin tab. Please note that although Cash App supports the Lightning Network, there is no option to choose the Lightning Network. This is because they are using a unified QR code.
However, this does not solve the problem of a single balance – the user’s BTC balance can still be split between the on-chain and the Lightning Network. This problem can be mitigated to some extent through Submarine swaps and/or Splicing, but my long-term view is that users may not even be aware that this is a problem, nor aware of the existence of the Lightning Network, as wallets and other providers will handle the underlying complexity and these issues will be hidden under a smooth user experience.
Misunderstanding 6: The Lightning Network is inefficient in terms of capital, so it is not feasible.
This discussion can be quite subtle, and I will try to remain neutral.
The Lightning Network adopts a hub-and-spoke model. Due to the high “unit capital allocation amount” ratio between exchanges, custodial wallets, LSPs, and the best routing nodes, the hub-to-hub part of the network has high capital efficiency.
However, the Lightning Network’s capital efficiency is low in the edges – non-custodial users. For custodial Lightning Network users, wallets only need to maintain large channels with other hubs 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 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 between them and the wallet provider, as well as every node along the way, the payment will be successful. But now the wallet encounters a problem – their side 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 preserve liquidity or extract liquidity by closing the channel (which would result in a bad user experience) or splicing the channel (which the user cannot see).
For non-custodial users, the problem of inefficient capital efficiency at the edge is a very annoying optimization problem. Objectively, no matter how large the transaction volume is, this is worse than the account-based model. However, this is not an unsolvable problem. As long as it is not infeasible, it can definitely succeed. This 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, because 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 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 advantages, and with the increase in on-chain fees, their advantages may become greater, because 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 full 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 been solved, and more problems will be solved in the next few years. Since the lightning has come, 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
Or users can run LND for manual operation
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
