Original title: Rethinking Lightning

Original author: benthecarman

Original link: https://stacker.news/items/379225

Original translation: BTCStudy


Over the past few months, I’ve felt like the Bitcoin community has been growing increasingly tired of the Lightning Network. And honestly, it makes perfect sense. In 2017, we were promised a decentralized payment network that would provide ever-cheap payments, and where everyone could run their own node. Today, the average Lightning user doesn’t actually use the Lightning Network, they just use a custodial wallet, and the few who do run a Lightning node often find it a cumbersome task. We at Mutiny Wallet have been trying to change all that by developing a lightweight self-custodial wallet, and I think we’ve done a good job of living up to that dream. In this post, I’ll analyze these issues, propose a new way of thinking about the Lightning Network, and argue what this means for the future of Bitcoin.

The first and most daunting of the Lightning Network’s UX challenges is channel liquidity. Today, no other payment system has this problem, so it often confuses many users. Worse, we don’t have any practical tricks to solve this problem. Muun Wallet uses a “one-chain wallet + submarine swap” model to get around this channel liquidity problem, which works very well until the day when fees start to go up and everyone realizes that it’s not a real Lightning wallet. A better solution is JIT liquidity, like we do at Mutiny, or channel splicing (which Phoenix has already implemented). (Translator's note: "JIT" is the abbreviation of "Just in time", which means "get it at any time". The general practice is that when a payment that exceeds the collection limit arrives, it will lead to the establishment of a new channel, so that the user can get enough collection limit.) These solutions partially abstract away the liquidity problem, but it is not enough. We often encounter users asking in the customer support channel why some payments have a fee and others do not. The fact is that channel liquidity is not a usable user experience for the vast majority of end users.

Another major pain point with the Lightning Network is the issue of offline payments. Essentially, you have to be online, using your private key, to sign and claim a payment. Technically, there is a spec proposal in progress that would solve this problem (essentially creating a notification system that tells users when they should come online to receive payments), but it doesn't solve the fundamental problem and is still limited. There have been some attempts to solve this problem, the most notable being Zeus Pay's Lightning Addresses. Essentially, it just creates a stuck payment and waits for the recipient to come online to receive it, which has caused countless problems for people and even forced us at Mutiny to ban users from paying them because it caused so many forced channel closures. This is a problem because the entire rest of the Bitcoin/cryptocurrency ecosystem works on the model where you can just copy-paste an address and then pay it at any time, without any warnings asking you to remind your friends to open their wallets. Things like Lightning Addresses even make it worse because it requires a network server to get you an invoice in the first place.

In my opinion, channel liquidity issues and offline collection issues are the two most obvious reasons why autonomous lightning wallets cannot become popular. When most users hear either of these two questions, they think "forget it" and switch to a custodial wallet because it's just so much easier. If we only have these two problems, I think the self-custody Lightning wallet is still good. It may not become the mainstream way for people to use the Lightning Network, but we can make the user experience good enough to allow a large part of the population to use self-sovereignty. way to use the Lightning Network. However, there are more problems beneath the surface.

Channel liquidity is an issue, but it can also be deceptive. When you have 100k satoshis to receive payments, you think you can expect to receive up to 100k satoshis, but you often don’t. This is because of on-chain fees. In a lightning channel, every time you make a payment, you need to create a new pre-signed transaction, which needs to have an output for each payment that is in progress (not yet completed), and these outputs affect the transaction volume, so they need to provide fees; the higher the network fee rate, the less liquidity you have (which is allocated to fees). When we solved most of the problems that caused forced channel closures in Mutiny, this issue became the most popular support request. Even if you do everything right, understand liquidity, and have enough liquidity for your payment, the payment may still not go through because the on-chain fees are too high. This is always disappointing because isn’t the whole point of the lightning network so that you don’t have to pay on-chain fees? Basically, all current lightning channels can be rendered useless if the on-chain fee rate becomes high enough because too much reserve is required for a payment. Obviously this is an exaggeration, but I hope I made it clear: on-chain fees not only affect the cost of opening and closing channels, even if you are a diligent node operator and only open channels when the fee rate is low, it is not enough, your channel needs to be large enough to pay the on-chain fee for each of your HTLCs at any time in the future, at any level of on-chain fee rate. As on-chain fees continue to rise, this problem will only become more serious.

Proposed solutions to this margin problem are “anchor channels”, “transaction package forwarding”, “one-time anchors”, etc. These ideas are all valuable and good, but they only mask the problem to some extent. They can indeed make the fee margin very low or even zero, however, the trade-off is that you need to have available on-chain funds to add the fee for your forced channel closing operation so that the transaction can be confirmed by the block. (Translator’s note: The core of the solution here is “CPFP”, using high-fee child transactions to increase the attractiveness of parent transactions; therefore, the parent transaction, in this case, the channel’s commitment transaction, can prepare no fees, and there is no problem of capital occupation. But the trade-off is as described by the author.) This once again breaks the user experience of self-custodial wallet users, because they must hold on-chain funds in addition to the lightning network funds so that they can add fees. And the size of the on-chain funds that need to be prepared is still dynamically dependent on the on-chain fee rate. Solutions to this problem include having others add fees for you, but this introduces a trusted third party, so it is not ideal.

As we list all the tradeoffs a Lightning node has to make, especially in a high-fee environment, it makes me wonder, what are we doing here? Are we on the wrong track? The Lightning Network is still an extremely powerful payment protocol from beginning to end, but its limitation is that it needs to scale. Basically every problem I listed disappears when you have a large Lightning node - you have a lot of liquidity and high uptime. We should optimize all of this. The market has been teaching us that for many years, 90%+ of Lightning users are using custodial wallets because it simply does a better job of scaling. So how can we use large-scale Lightning nodes without using custodial wallets?

Unfortunately, the combination of the existing massive Lightning infrastructure and self-custodial solutions is still not enough. So far, the only real way to do this is the Muun Wallet we mentioned earlier, but it doesn’t really solve the problem because everything is just on-chain transactions. However, Muun did some things right. Designing an architecture for a simpler protocol interface to the Lightning Network was a genius idea and gave us the best of both worlds. We can issue fast and cheap payments and let the big boy collect the fees by running a Lightning node. The just launched Aqua Wallet is essentially a Muun Wallet, just on Liquid, which is a good stopgap solution but does not fundamentally solve the problem.

Before we move on, 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 only need on-chain payments. However, we live in the real world and have a 1MB block size limit that limits the number of transactions we can confirm on-chain. Lightning Network is a huge improvement to Bitcoin because instead of publishing every transaction to the chain, we can just open a channel and then make virtually unlimited payments. So why didn’t Lightning Network kill it? Because Lightning Network allows us to move payments off-chain, but it doesn’t allow us to move ownership off-chain. Fundamentally, Lightning Network still relies on the fact that, ultimately, a UTXO will belong to a user. So even if every transaction on-chain belongs to a Lightning channel, we still run into a limit - there are only a limited number of people who can own their own channels. What we need is another Layer 2 that can expand the ownership of utxo and interact with the Lightning Network, so that we have a way to expand the ownership capacity while expanding the payment capacity.

So how do we expand the capacity of ownership? In short, the answer today is custody, whether it is a pure custodian (such as Wallet of Satoshi) or in a gray area (such as fedimint and Liquid), the only way we can use today is custody or federation bridge. On Bitcoin, the only way to entrust the ownership of a UTXO to multiple parties is multi-signature, however, it requires every user to be online when any user wants to interact, and, when you go far enough along this path, you will just reinvent the Lightning Network.


So are we doomed? Is there no way to scale Bitcoin in a self-sovereign way? Fortunately, the answer is no, but we'll need some soft forks. Covenants are the way to expand ownership capacity. There are many, many covenant proposals, but at the end of the day, all they propose is adding a way for you to have a Bitcoin address that limits where and how the funds in it can be spent. This may seem strange, but we already have something like this in Bitcoin today, OP_CTLV (CheckLockTimeVeiry), which was activated in the 2016 soft fork, which only allows you to spend funds in a Bitcoin address using transactions with a given locktime value, so it allows you to gate how long a UTXO can be spent. What the current covenant proposal does is allow you to gate where a UTXO can be spent. With this simple component, we can develop many different protocols that allow for expanded ownership capacity.

However, the future is not bleak, even without the cap clause, we can still scale Bitcoin, just not in the ideal way. At Mutiny, we are working hard to implement fedimint in the wallet, which I personally (and others on our team) believe is the best scaling solution for Bitcoin at the moment. Fedimint gives us the ability to dynamically share ownership with a group of people, and can interact with the Lightning Network through gateways. This is the pinnacle of the Bitcoin scaling dream with current technology, and we will spare no effort to help make it a reality.