Rethinking the Lightning Network: Fully Realizing the Bitcoin Scalability Dream

Original Title: 《Rethinking Lightning》

Original Author: benthecarman

Compilation: BTCStudy

Over the past few months, I have felt an increasing sense of fatigue within the Bitcoin community regarding the Lightning Network. To be honest, this is entirely understandable. In 2017, the promise we received was that this would be a decentralized payment network, always providing cheap payments, and everyone could run their own node. Today, ordinary users of the Lightning Network are not actually using it; they are just using a custodial wallet. Meanwhile, the few users who run Lightning nodes often find it to be a burdensome task. Our colleagues at Mutiny Wallet have been trying to change this by developing a lightweight self-custody wallet, and I believe we have made significant progress toward realizing this dream. In this article, I will analyze these issues, and propose a new perspective on understanding the Lightning Network, then argue what this means for the future of Bitcoin.

The first and most daunting challenge in the user experience of the Lightning Network is channel liquidity. (Translator's note: This means that users not only have a balance for payment but also a balance for receiving payments.) Today, apart from the Lightning Network, no other payment systems face this issue, which often confuses many users. Worse still, we have no practical tricks to solve this problem. Muun Wallet circumvents the channel liquidity issue by using a "one on-chain wallet + submarine swap" model, which works very well under normal circumstances, until the day fees rise, when every user realizes it is not a true Lightning wallet. (Translator's note: In this model, users do not create channels with anyone but achieve Lightning payments through on-chain and off-chain fund swaps; whenever a user needs to initiate a Lightning payment, they must make an on-chain transaction. Thus, the user's payment cost is tied to the network fee rate, which becomes apparent when rates rise.) A better solution is JIT liquidity, as we do at Mutiny, or channel stitching techniques (which Phoenix has already implemented). (Translator's note: "JIT" stands for "Just in time," meaning "available whenever needed," and the general approach is that when a payment exceeds the receiving limit, it leads to the creation of a new channel, allowing the user to obtain sufficient receiving capacity.) These solutions partially abstract away the liquidity issue, but it is still not enough; we often encounter users asking in customer support channels why some payments incur fees while others do not. The fact is, channel liquidity is not a usable user experience for the vast majority of end users.

Another major pain point of the Lightning Network is the issue of offline payments. Fundamentally, you must be online to sign and claim a payment with your private key. Technically, there is an ongoing proposal for a specification that could solve this problem (essentially creating a notification system to inform users when they should go online to receive payments), but it does not address the fundamental issue and still has limitations. There have also been attempts to solve this problem, the most famous being the Lightning address from Zeus Pay. Essentially, it just creates a stuck payment and waits for the recipient to go online to receive it, which brings countless problems, even forcing us at Mutiny to prohibit users from paying them because it leads to numerous forced channel closure events. This is a dilemma because the operational model of all other Bitcoin/cryptocurrency ecosystems is that you just need to copy-paste an address and can pay it anytime without any warning reminding you to tell your friend to remember to open their wallet. Things like Lightning addresses even exacerbate the situation because they require a network server from the start to enable you to receive invoices.

I believe that the channel liquidity issue and the offline payment issue are the two most significant reasons why self-custody Lightning wallets have not gained popularity. The vast majority of users hearing either of these two problems will think "forget it," and then switch to using a custodial wallet because it is simply much easier. If we only had these two issues, I think self-custody Lightning wallets would still be good; they might not become the mainstream way people use the Lightning Network, but we could make the user experience good enough to allow a significant portion of people to use the Lightning Network in a self-sovereign way. However, beneath the surface, there are more problems.

Channel liquidity is a problem, but it is also deceptive. When you have a receiving capacity of 100,000 satoshis, you might think you can receive payments of up to 100,000 satoshis, but that is not the case; you often receive no payments at all. This is due to on-chain fees. In a Lightning channel, every time you make a payment, you need to create a new pre-signed transaction, and this transaction needs to allocate an output for each payment being processed (not yet completed), and these outputs affect the size of the transaction, thus requiring fees; the higher the network fee rate, the less liquidity you have (as it is allocated to fees). As we resolved most of the issues leading to forced channel closures at Mutiny, this problem became the most frequent customer support request. Even if you do everything right, understand liquidity, and have prepared enough liquidity for your payments, they may still fail due to high on-chain fees. This is always disappointing because the whole point of the Lightning Network is that you shouldn't have to pay on-chain fees, right? Essentially, all current Lightning channels can become useless due to high on-chain fee rates because a single payment requires too much collateral. Clearly, this is an exaggeration, but I hope I have made my point clear: on-chain fees not only affect the cost of opening and closing channels, but even if you are a diligent node operator who only opens channels when fees are low, that is still not enough; your channels need to be large enough to cover on-chain fees for every HTLC payment at any level of on-chain fee rates in the future. As on-chain fees continue to rise, this problem will only worsen.

Proposed solutions to this collateral problem include "anchor channels," "transaction package forwarding," "one-time anchors," and so on. These ideas have value and are good, but to some extent, they merely mask the problem. They can indeed make the fee collateral very low, even zero, however, the trade-off is that you need on-chain funds available to add fees for your forced channel closure operations so that the transaction can get block confirmation. (Translator's note: The core of the solution here is "CPFP," using high-fee child transactions to enhance the attractiveness of the parent transaction; thus, the parent transaction, in this case, is the commitment transaction of the channel, which can be opened without preparing any fees, thus avoiding the fund occupation issue. But as the author mentioned, there is a trade-off.) This again breaks the user experience for self-custody wallet users because they must hold on-chain funds outside of Lightning Network funds to add fees. The amount of on-chain funds needed still dynamically depends on the on-chain fee rate. Solutions to this problem include having others help you add fees, but this introduces a trusted third party, which is not ideal.

When we list all the trade-offs a Lightning node needs to make, especially the impact of high-fee environments on it, I can't help but wonder, what are we really doing? Are we on the wrong path? The Lightning Network is still an extremely powerful payment protocol from start to finish, but its limitation is that it needs to scale. Essentially, every problem I have listed disappears when you have a large Lightning node—you have ample liquidity and high uptime. We should optimize all of this. The market has been educating us; for many years, over 90% of Lightning users have been using custodial wallets because they simply perform better at scaling. So, how can we use large-scale Lightning nodes without using custodial wallets?

Unfortunately, the combination of existing large-scale Lightning Network infrastructure and self-custody solutions still falls short. So far, the only real way to achieve this is through the aforementioned Muun Wallet, but it doesn't truly solve the problem because everything is just on-chain transactions. However, Muun has done some things right. Designing a simpler protocol interface to the Lightning Network is a brilliant idea and gives us the best of both worlds. We can initiate fast and cheap payments while allowing that big boy to collect fees by running a Lightning node. The newly launched Aqua Wallet is essentially a Muun Wallet, but on Liquid, which is a good stopgap but does not fundamentally solve the problem.

Before we move forward, we should take a step back and analyze what problem we are trying to solve. Bitcoin has a fundamental scaling limitation: its block size. If we could have unlimited block size, we wouldn't need any Layer 2 solutions because we would only need on-chain payments. However, we live in the real world, and there is a 1 MB block size limit that restricts the number of transactions we can confirm on-chain. The Lightning Network is a tremendous enhancement to Bitcoin because we do not need to publish every transaction on-chain; we only need to open a channel and can initiate almost unlimited payments. So why hasn't the Lightning Network solved everything? Because while the Lightning Network allows us to move payments off-chain, it has not enabled us to transfer ownership off-chain. Fundamentally, the Lightning Network still relies on the fact that, ultimately, a UTXO will belong to a specific user. So, even if every transaction on-chain belongs to a Lightning channel, we still hit a limit—the number of people who can own their channels is ultimately finite. What we need is another Layer 2 that can expand UTXO ownership and interact with the Lightning Network, allowing us to scale both payment capacity and ownership capacity.

So, how do we expand ownership capacity? Simply put, today's answer is custody, whether it is pure custodians (like Wallet of Satoshi) or those in the gray area (like fedimint and Liquid), the only way we can use today is through custodial or federated bridges. On Bitcoin, the only way to delegate ownership of a UTXO to multiple parties is through multi-signature, however, it requires every user to be online whenever any user wants to interact, and when you go far enough down this path, you will ultimately just reinvent the Lightning Network.

Are we doomed to fail? Is there no way to scale Bitcoin in a self-sovereign manner? Fortunately, the answer is no, but we need some soft forks. Covenants are the way to expand ownership capacity. There are many covenant proposals, but at their core, they propose adding a way for you to have a Bitcoin address that restricts where and how the funds can be spent. This may seem strange, but we already have something like this in today's Bitcoin, OP_CTLV (CheckLockTimeVerify), which was activated in the 2016 soft fork, allowing you to spend funds in a Bitcoin address only using transactions with a given locktime value, thus allowing you to control the time a UTXO can be spent. Current covenant proposals aim to allow you to control where a UTXO can be spent. With this simple component, we can develop many different protocols that allow for expanding ownership capacity.

However, the future is not bleak; even without covenants, we can still scale Bitcoin, just not in an ideal way. At Mutiny, we are fully committed to implementing fedimint in wallets, and I personally (as well as others on our team) believe this is the best scaling solution for Bitcoin currently. Fedimint gives us the ability to dynamically share ownership with a group of people and interact with the Lightning Network through gateways. This is the pinnacle of Bitcoin scaling dreams under current technology, and we will spare no effort to help make it a reality.