Over the last few months it feels the bitcoin community has gotten more and more jaded on lightning. To be honest, this is for good reason, back in 2017 we were promised a decentralized payment network that would always have cheap payments and everyone would be able to run their own node. Nowadays, the average lightning user actually isn’t using lightning, they are just using a custodial wallet and the few of that do run lightning nodes often find it a burdensome task. For us at Mutiny Wallet, we are trying to make this better by creating a lightweight self-custodial wallet and in my opinion we have been executing on that dream fairly well. In this post, I’ll analyze these issues and present a new way to view lightning and what that means for bitcoin going forward.
First and foremost one of the hardest UX challenges of lightning is channel liquidity. No other payment system has these problems today besides lightning so this often confuses lots of users. To make matters worse, there aren’t any practical hacks that we can do to get around this. Muun Wallet used an on-chain wallet + submarine swaps to get around the channel liquidity problem, this worked very well until fees went up and everyone realized it wasn’t actually a lightning wallet. The better solution is JIT liquidity like we do in Mutiny or splicing like that is done in Phoenix. These solutions abstract some of it away but not enough, we often get support questions confused on why some payments have fees and others do not. The fact is channel liquidity is not a usable UX for most end users.
The other major pain point of lightning is the offline receive problem. Inherently, you must be online with your private keys to sign and claim a payment. There is technically an ongoing spec proposal to be able to work around this (essentially creating a notification system of when people are online to receive payments), but it doesn’t solve the fundamental problem and still has limitations. There has been a few attempts to get around this, most notably was Zeus Pay lightning addresses. These essentially worked by just creating stuck payments and waited for the user to come online to claim, this caused a ton of problems for people and even forced us at Mutiny to block users from paying them because it caused so many force closures. This is a hard problem because the entire rest of the bitcoin/crypto ecosystem works by just copy-paste an address and you can send to it whenever, there isn’t caveats around asking your friend to open their wallet. This is further exacerbated by things like lightning address that requires a webserver to even get an invoice in the first place.
Channel liquidity and offline receives in my opinion are the two most obvious reasons why self-custodial lightning is not popular. When most users hear about any of these, they just think screw that and move to a custodial wallet because it is so much easier. If these were our only two problems, I think self-custodial lightning would be fine, it may never be the predominant way people use lightning, but we could get the UX good enough that we have a significant portion of people using lightning in a sovereign way. However, there are more problems under the surface.
Channel liquidity is a problem, but it is also deceptive. When you have 100k sats of inbound liquidity you would think you could receive up to 100k sats, but this isn’t the case, often you can’t actually receive any. This is because of on-chain fees, when a payment is being made in lightning you are creating pre-signed transactions that have outputs for every in-flight payment, these outputs cost potential on-chain fees and the high on-chain fees go the more it eats into your liquidity. After we’ve solved most of our force close issues Mutiny this has been number one support request. Even if you do everything right, understand liquidity and have enough for your payment, sometimes it still won’t work because on-chain fees are too high. This is always really discouraging because isn’t the whole point of lightning to not have to pay on-chain fees? Fundamentally, all current lightning channels could become entirely useless if on-chain fees went high enough because a single payment would require too many reserves. Obviously this is hyperbolic, but I hope I am getting the point across that on-chain fees don’t just effect the opening and closing costs of channels, even if you are a diligent node runner that only opens channels when fees are low, that is not enough, your channels need to be large enough to pay for the on-chain fees of each HTLC at any future on-chain fee rate. As on-chain fees go up and up this problem will only get worse.
The proposed solution to these reserve issues are things like anchor channels, package relay, ephemeral anchors, etc. These are all well and good but kind of just mask the problem. They do solve it so the fee reserve can be much lower and possibly zero, however with the tradeoff that you need on-chain funds available to fee-bump your force closes so they can actually get into a block. This again breaks the UX for self-custodial users because they have hold on-chain funds alongside their lightning funds so they can do those on-chain fee bumps. The size requirements for their on-chain funds is still dynamically based on how high on-chain fees can spike. Solutions for this can include having someone else bump your transaction fees but this brings basically a trusted 3rd party into the mix and isn’t ideal.
When you lay out all the different tradeoffs a lightning node needs to make, especially in a high fee environment, it makes me think, what are we doing here, are we going down the wrong path? Lightning is still fundamentally a fantastic payment protocol but its limitation is that it requires scale. Basically every problem I’ve outlined goes away when you have a large lightning node with lots of liquidity and high uptime so many we should optimize for that. The market has been telling us this for years already, +90% of lightning users are using custodial wallets because it works so much better at scale. So how can we use large scale lightning nodes without custodial wallets?
Combining existing large scale lightning infrastructure with self-custodial solutions sadly, isn’t totally possible. The only real way to do that as of now is Muun Wallet which as we talked about earlier, doesn’t really solve the problem because everything is just an on-chain transaction. However, Muun was onto something. The architecture of having a simpler protocol interface with lightning is genius and gives us the best of both worlds. We can make fast cheap payments and let the big boys collect fees for running the lightning node. Aqua Wallet just launched which is essentially a Muun Wallet but on top of Liquid, this is a good bandaid fix but doesn’t get to the root of the problem.
Before we go further we should take a step back and break down what problems we are trying to solve. Bitcoin has a fundamental scaling limitation through the block size, if we could make infinite, then we wouldn’t necessarily need any layer 2s because we could just make on-chain payments. However, we live in the real world and have a 1mb block size limit, and this limits the number of transactions we can make on-chain. Lightning is a huge improvement to bitcoin because we don’t need to put every transaction on-chain, we just need to open a channel and can make seemingly countless payments. So why isn’t lightning the silver bullet? Lightning lets us move payments off-chain but what it doesn’t do is let us move ownership off-chain. Fundamentally lightning still relies on that, at the end of the day, a utxo goes to single user. So even if every on-chain transaction was a lightning channel, we still run into the limit of how many people can actually own those channels. What we need is another layer 2 that can scale utxo ownership and caninterop with lightning, that way we have a way to scale ownership combined with scaling payments.
So how do we scale ownership? Simply put, the answer today is custody, whether that is pure custodial like a Wallet of Satoshi or in the grey area like fedimints and liquid, the only way to do it today is through custody or federated bridges. In bitcoin, the only way to delegate ownership of a utxo to multiple parties is through multisig, however, that requires every user to be online when anyone wants to transact, and when you take go down this path far enough you end up just reinventing lightning.
Are we doomed then? Is there no way to scale bitcoin in a self-sovereign way? Luckily, the answer is no, but we need some soft-forks. Covenants are the way to scale bitcoin ownership. There are a bunch of covenant proposals but at their core what they propose to do is to add a way, so you can have a bitcoin address that limits where and how the coins in it can be spent. This can seem scary, but we already have these in bitcoin today, OP_CTLV (Check LockTime Verify), which was soft forked in 2016, only allows you to spend from a bitcoin address if the transaction has a given locktime, this lets you gate when a utxo can be spent. What the current covenant proposals do is let you gate where a utxo can be spent. With that simple primitive many different protocols can be built that allow for scaling ownership.
There are a lot of current covenant proposals, the main ones being: OP_CTV, OP_VAULT, OP_CSFS, OP_TXHASH, OP_CAT, and APO. They all have different functionality and tradeoffs but in my opinion we should be looking towards activating a form of covenants because otherwise we will likely be moving towards a future of less sovereign bitcoin users.
The future is not bleak however, even without covenants we can still scale bitcoin for the world, just not in the ideal way. At Mutiny, we are full steam ahead on implementing fedimint into the wallet, in my opinion (and the rest of the team’s) it looks like the best current scaling solution for bitcoin. Fedimints give us the ability to dynamically share ownership over a group of utxos and is able to interop with lightning through gateways. It is the pinnacle of the scaling dream for bitcoin with current technology and I can’t wait to help make it reality while we can.