Partnered With:

Rethinking the Lightning Network.

Read this article in 16 Minutes

Fedimint enables dynamic sharing of ownership with a group of people and interacts with the Lightning Network through a gateway, representing the pinnacle of Bitcoin scaling dreams under current technology.

Original Title: "Rethinking Lightning"

Original Author: benthecarman

Translated by: BTCStudy

Over the past few months, I have felt that the Bitcoin community has become increasingly tired of the Lightning Network. To be honest, this makes sense. In 2017, we were promised a decentralized payment network that would always provide cheap payments and allow everyone to run their own node. Today, the average user of the Lightning Network actually does not use the Lightning Network, they only use a custodial wallet; and the few users who run Lightning nodes often find it to be a heavy task. Our colleagues at Mutiny Wallet have been trying to change this by developing a lightweight self-custody wallet, and I believe we have achieved this dream very well. In this article, I will analyze these issues, propose a new perspective on understanding the Lightning Network, and argue what this means for the future of Bitcoin.

The first and most difficult challenge in the user experience of the Lightning Network is channel liquidity. (Translator's note: This means that users not only have a balance or payment limit, but also a receiving limit.) Today, no other payment system besides the Lightning Network has this problem, which often confuses many users. Worse still, we have no practical tricks to solve this problem. The Muun Wallet uses a "one-chain wallet + submarine exchange" model to bypass this channel liquidity problem, which works very well in normal times, until the day when fees rise, and every user realizes that it is not a true Lightning wallet. (Translator's note: In this mode, users do not create channels with anyone, but achieve Lightning payments by exchanging on-chain and off-chain funds; every time a user needs to initiate a Lightning payment, they have to make an on-chain transaction. So the user's payment cost is linked to the network fee rate, and is exposed when the rate rises.) A better solution is JIT liquidity, as we do at Mutiny, or channel splicing technology (already implemented by Phoenix). (Translator's note: "JIT" is short for "Just in time", which means "get it at any time". The general approach is that when a payment exceeding the receiving limit arrives, it will lead to the establishment of a new channel, so that users can obtain sufficient receiving limit.) These solutions partially abstract the liquidity problem, but not enough. We often encounter users asking why some payments have fees while others do not in customer support channels. The fact is that 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. Essentially, you must be online and use your private key to sign and claim a payment. Technically, there is a proposed specification in continuous progress that can solve this problem (essentially creating a notification system to inform users when they should go online to receive payments), but it does not solve the fundamental problem and still has limitations. There have also been attempts to solve this problem, the most famous of which is Zeus Pay's Lightning Address. Essentially, it only creates a stuck payment and waits for the payee to come online to receive the payment, which has caused countless problems and even forced us at Mutiny to prohibit users from paying them because it has caused many forced channel closure events. This is a problem because the working mode of all other Bitcoin/crypto currency ecosystems is that you only need to copy-paste an address and you can pay to this address at any time without any warning to remind your friends to open their wallets. Things like Lightning Address even make it worse because it requires a network server from the beginning to allow you to get an invoice.

I believe that the liquidity problem of channels and the issue of offline payments are the two most significant reasons why self-custody lightning wallets cannot become popular. Most users, upon hearing either of these two problems, would think "forget it" and switch to using a hosted wallet because it is much easier. If these were the only two problems, I think self-custody lightning wallets would still be good, perhaps not as the mainstream way for people to use the lightning network, but we can make the user experience good enough to enable a large portion of the population 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 receipt limit of 100,000 satoshis, you may think that you can receive up to 100,000 satoshis in payment, but that is not the case. You often do not receive any payments because of on-chain fees. In the Lightning Network, every time you make a payment, you need to create a new pre-signed transaction, and this transaction needs to arrange an output for each payment that is being processed (not yet completed). These outputs will affect the volume of the transaction, so fees need to be provided for them; the higher the network fee rate, the less liquidity you have (allocated to fees). When we solved most of the problems that caused Mutiny to force close the channel, this problem became the most common customer service request. Even if you do everything right, understand liquidity, and prepare enough liquidity for your payment, the payment may still fail because the on-chain fees are too high. This is always disappointing because the whole point of the Lightning Network is that you don't have to pay on-chain fees, right? Basically, all current Lightning channels can become useless because of high on-chain fees, because a payment requires too much reserve. Obviously, this is an exaggeration, but I hope I have made it clear: on-chain fees not only affect the cost of opening and closing channels, but 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 on-chain fees for every HTLC payment 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.

The proposed solutions for this margin issue are "anchor channels", "transaction package forwarding", "one-time anchors", and so on. These ideas are valuable and useful, but to some extent, they only mask the problem. They can indeed make the transaction margin very low, even zero. However, the trade-off is that you need to use on-chain funds to add fees to the operation that forces you to close the channel, so that the transaction can be confirmed in the block. (Translator's note: The core of the solution here is "CPFP", which uses high-rate sub-transactions to increase the attractiveness of parent transactions. Therefore, the parent transaction, which is the commitment transaction of the channel here, can be prepared without any fees, and there is no problem of fund occupation. But as the author said, there are trade-offs.) This once again breaks the user experience of self-custody wallet users, because they must hold on-chain funds outside the Lightning Network funds in order to add fees. The size of the on-chain funds that need to be prepared still depends on the on-chain fee rate. The solution to this problem includes letting others help you add fees, but this introduces a trusted third party, so it is not ideal.

When we list all the trade-offs that a lightning node needs to make, especially the impact of high transaction fees, 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, but its limitation lies in the need to scale. Basically, every issue I've 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 for so many years that over 90% of lightning users are using custodial wallets because they do better in scaling. So, how can we use large lightning nodes without using custodial wallets?

Unfortunately, despite the existing large-scale Lightning Network infrastructure and self-custody solutions, we still fall short. So far, the only real way to achieve this is through 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 that provides 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 and let the big boy collect fees by running a Lightning node. The newly launched Aqua Wallet is essentially a Muun Wallet, but on Liquid, which is a good workaround, but it doesn't 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 could just do on-chain payments. However, we live in the real world and have a 1 MB block size limit, which limits the number of transactions we can confirm on-chain. The Lightning Network is a huge improvement for Bitcoin because we don't need to publish every transaction to the chain, we just need to open a channel and can then initiate almost unlimited payments. So why isn't the Lightning Network a silver bullet? Because it allows us to move payments off-chain, but not ownership. Fundamentally, the Lightning Network still relies on, ultimately, a UTXO belonging to a user. So even if every on-chain transaction belongs to a Lightning channel, we still hit a limitation - the number of people who can have their own channel is ultimately limited. What we need is another layer 2 that can extend the ownership of UTXOs and can interact with the Lightning Network, so that we can expand the capacity of both payments and ownership.

So, how do we expand the capacity of ownership? Simply put, the answer today is custody, whether it's pure custody providers (such as Wallet of Satoshi) or those in the gray area (such as fedimint and Liquid), the only way we can use today is custody or consortium bridges. In Bitcoin, the only way to delegate ownership of a UTXO to multiple parties is through multisignature, but it requires that every user be online when they want to interact, and when you go far enough down this road, you'll end up reinventing the Lightning Network.

So are we destined to fail? Is there no way to expand Bitcoin in a sovereign way? Fortunately, the answer is no, but we need some soft forks. Covenants are a way to expand ownership capacity. There are many covenant proposals, but ultimately they propose adding a way for you to own a Bitcoin address that can restrict where and how funds are spent. This may seem strange, but we already have this in today's Bitcoin with OP_CTLV (CheckLockTimeVerify), which was activated in a soft fork in 2016. It only allows you to spend funds in a Bitcoin address with a given locktime value, so it allows you to put a time lock on spending a UTXO. The current covenant proposals allow you to put a lock on 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 restriction clauses, we can still expand Bitcoin, but not in an ideal way. At Mutiny, we are working hard to implement fedimint in wallets, which I personally (and others on our team) believe is the best current solution for Bitcoin's scalability. 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's scalability dream under current technology, and we will spare no effort to help make it a reality.