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
It’s been a while since I last used Lightning Network.
- Why does Binance continue to attract new users despite regulatory challenges?
- A Review of 10 New Projects Worth Paying Attention to Recently
- Data Reveals the Profit Strategies of the Top 15 NFT Tycoons Nearly $300 Million in Profits, These Projects Have the Highest Investment Returns
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 the 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 haven’t recently used the Lightning Network. It will discuss misconceptions that I or others have observed. If I miss any good points, please leave me a message on Twitter.
Misconception 1: Running your own node is necessary to use the Lightning Network in a non-custodial manner, which prevents ordinary users from using mobile devices.
It used to be the case a few years ago, but now users can use the 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 the same as using Ethereum and making RPC calls to Alchemy or Infura wallets.
Misconception 2: Both the sender and receiver must be online at the same time for Lightning Network payments to be successful (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 load limitations.
In the long run, Lightning Network protocol developers are developing the Async Payments specification, which will achieve arbitrary-length trustless delays. Essentially, the payment will be recorded in 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, usually 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, this 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 deposit 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 deposit funds into the channel, and the recipient can be a brand new empty address. This misconception stems from the Lightning Network whitepaper, which has always used examples of bidirectional funding 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 bi-directional payments with double funds, and the channels do not have an expiration time. 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.
Misconception 4: The Lightning Network requires users to specify specific, single-use invoices, which is a very bad user experience.
At the beginning, this was indeed true. But now there are Lightning Network addresses, which are 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 quantity and duration.
Misconception 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 not anymore. 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 CashApp 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 may still be split between the blockchain and the Lightning Network. This problem can be partially solved 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, because wallets and other providers will handle the underlying complexity, and these issues will be hidden under a smooth user experience.
Misconception 6: The Lightning Network is inefficient in terms of capital efficiency, 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, where the Lightning Network network’s capital efficiency is low is at the edge – 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 is how to maintain continuous liquidity distribution 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 channels between them and the wallet provider, 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 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 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 frustrating optimization problem. Objectively, regardless of the size of the transaction, this is worse than the account-based model. However, this is not an unsolvable problem. As long as it is not infeasible, it will 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 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 increase to 30 to 60 US dollars, the scale cost of channel management will be extremely high, 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 advantages, and as on-chain fees increase, their advantages may become even greater, as their omnibus account mode 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. 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 will be solved in the coming years. Since lightning has come, will 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 also run LND for manual operations.
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!
