Expanding the Lightning network to serve billions – a quick win strategy

This text is a part of my new book The Orange Flash of Freedom: Understanding and using the Bitcoin Lightning network

As Bitcoin blocks are being filled and fees rise astronomically, it has become too expensive to open channels for many day-to-day use-cases, especially in global south. In this blog I want to build a case for expanding the Lightning network beyond the bloated Bitcoin time-chain (also called a blockchain), to give people more options.

First, let’s look at how Lightning actually uses Bitcoin timechain. Lightning is a separate payment network that allows to send and receive Bitcoin. It uses a cryptoanarchist strategy of “prepaid fine” and some clever game-theory to make sure no one cheats. In case of Lightning, the cheating would be trying to settle a channel balance with an outdated state, which would be punished by an on-chain transaction that takes the cheater’s whole channel balance.

Lightning has different properties than Bitcoin time-chain – better privacy, lower fees, instant settlement. Also, it is non-custodial – we are sending real Bitcoin, not a derivative (each channel close transaction settles the correct balance on-chain, but you do not need to close channels to settle).

There are two problems with traditional use of Lightning and both relate to scaling. One is that for many, the on-chain fee is already prohibitive. People living on $1 a day or less can’t pay several dollars just to have a (small) channel open to them.

Another problem is the real capacity. Let’s say we want to onboard one hundred million more users. Assuming a channel opening transaction of cca 150vB, we can realistically open around 5000 channels per each block, which would take around 138 days assuming Bitcoin time-chain would not be used for anything else. And in this case, the fees would be extremely high anyway.

Expanding Lightning

It is possible to open Lightning channels without the implicit Bitcoin backing. These are called hosted channels or unbacked channels. For example I can open a channel with someone, use it to access the whole Lightning network and then settle however I want – with cash, it can be a credit account, etc. What is important is that the receiver of such transaction does not need to know that the transaction happened via hosted channel, they receive Bitcoin through the channels that they have opened.

This allows us to use different accounting methods than Bitcoin on-chain transactions, if the unit of account is the same.

One nice real-world example of this approach is using Cashu or Fedimint protocols, which are based on a technology called chaumian e-cash, to settle Lightning invoices. Another example would be to use Liquid network with a swap service to do the same. For example Aqua Wallet uses atomic swaps between Liquid on-chain and Lightning. You still need to settle a liquid transaction (blocks are generated once per minute), so the transactions are not instant, but there is no need to open a channel for each user on Bitcoin main time-chain.

Using Liquid to expand Lightning

An obvious and super easy way would be to use the Liquid side-chain not using atomic swaps, but for opening channels. Before you start with “it is not decentralized, …”, yes, I agree and I do not like it that much either. But bear with me, this is still much better than the custodial wallets!

Imagine a consumer wallet like Phoenix or Breez, allowing you to choose opening channels on Liquid instead of Bitcoin timechain, with much lower fees.

People could run hosted channels between Liquid and Bitcoin timechains, essentially making money on bridging – this could be even provided by the provider of the wallet to earn some additional revenue. Please note that hosted channels in this case are trustless, it is a channel between two nodes of the same node operator (each operator implicitly trusts himself or herself).

End-users would choose if they want channels on Bitcoin timechain for higher fees and higher security, or if it is a “coffee budget” that is not very important. What is crucial here is that merchants would receive normal Bitcoin, because the payment would be routed trustlessly through the bridge. The Lightning network would expand and use different backing mechanisms that are suited for different users. Merchants want “real bitcoin”, customers want low fees. And we can have both.

There can also be a “one-click” conversion tool, for example in times of lower fees on Bitcoin chain, which would just create a lightning payment through the bridge to oneself, opening an incoming channel in the process. We could have a feature saying “when the value of Bitcoin is over $100, route to Bitcoin chain automatically, opening a channel on the way”. This consolidates incoming channels, improves security when it matters, but allows for cheap and fast on-boarding. It could also allow batched channel opening – when the provider sees that the fees are low, it could ask you to cooperate in a transaction that opens multiple channels in one transaction.

Advantages for users

Users would get easier onboarding and lower fees. The user interface could be kept simple, there is no different invoice format or anything, it is just Lightning, backed by bridged coins. It can be entirely opt-in and would show people the power of Bitcoin without the initial fees and frustration.

Liquid is not very decentralized I do not own any L-BTC, but I believe this could improve user experience.

Advantages for merchants

Merchants can decide to receive only Bitcoin backed by real Lightning channels. To do this, they do not need to do anything. They get access to customers who opened these Liquid-backed channels for free. Less fees paid to miners – more money to be spent for coffee in your coffee shop!

On the other hand, if they do not have incoming liquidity, they could decide to allow automatic incoming channel opening on Liquid (Phoenix-style) and then consolidate once a week (or even swap-out to onchain hardware-wallet-protected address).

Merchants do not want business to go down, because the customers are hesitant to fund their wallets in times of high fees.

Advantages for wallet providers

Wallet providers can keep more of the channel creation fee for themselves if they do not have to pay miners. They can also earn fees on bridging and swapping balances from Liquid-backed to Bitcoin-backed. This whole operation is trustless.

They can also get more users by lowering the fees and making their project more attractive. Integrating with some parts of the wider ecosystem – Nostr for zaps, podcasting 2.0, … – requires low fees, the entry fees cannot be too high.

Advantages for Bitcoin and Lightning

In money, network effects are everything. Reducing friction enables on-boarding more users, on-boarding more users expands value of the network and that pumps your bags. Let’s do it!

How to do it?

To build a bridge, you need to run two core lightning instances (one on Bitcoin, one on Liquid) and create a hosted channel. There is no code to write, core lightning already supports Liquid. Set the fees, you are good to go.

So the only thing would be to allow lightning for consumer end-user wallets. Here unfortunately, there is no good Liquid support, because the end-user wallets do not run core lightning, but either lnd or acinq’s lightweight Lightning implementation. It should not be too difficult to add.

Why not Litecoin, …?

For this to work the unit of account needs to be the same. Litecoin also has a Lightning implementation, but it sends Litecoins, not Bitcoin. So there would need to be unit of account conversion, which introduces exchange rates and a lot of unnecessary friction. Also, we do not want to teach new Bitcoiners to have Litecoin.

But isn’t it custodial?

No, it is not. Let me explain the security design and risks that differ to Bitcoin timechain-backed channels. Feel free to skip this part if you are not into technical details of Bitcoin and Liquid.

• You need to trust the backing on Liquid chain. This is not ideal, Bitcoin is protected by huge hashpower, Liquid is protected by quite a large, but still limited “federation”. Cheating would be obvious though and many different entities would have to cooperate to steal your “coffee money”. Liquid still has nodes and timechain, so you cannot simply take coins without knowing the opening transaction’s two multisig private keys.
  • The biggest threat is transaction censorship by validators. This can happen, but also note, that you can get out using Lightning, without an on-chain transaction. So both your channel counterparty and Liquid would need to censor.
  • Another threat is Liquid stealing the BTC (intentionally or unintentionally) by releasing the locked BTC from the peg-in multisig. Again, this would be clearly visible and much bigger issue than my coffee money. Also, these coins would probably be immediately tainted on Bitcoin timechain.
• No one needs to trust the hosted channel and the bridge. The hosted channel is between bridge operator’s two Lightning nodes – essentially the bridge operator receives L-BTC through one channel and sends BTC through another channel of theirs. This L-BTC<->BTC exchange does not need channel backing, because it is atomic and trustless. The bridge will collect fees for this service, because they probably need to rebalance from time to time, but that’s it. You as a user (or your lightning wallet) can find the path with the cheapest bridge – sometimes even with negative fees if you help them rebalance.
• The merchants that want Bitcoin-backed Lightning balance do not have to deal with nor even know about the fact that the payment originated through Liquid. The payment arrives through one of their open channels, if they do not support Liquid, there is no difference.

So basically the only entity to trust here is the Liquid federation for validating transactions and maintaining the bridge. And even this trust requirement can be greatly reduced, because it cannot be easily targeted. This expansion of Lightning actually reduces the risk of the federation multisig, because there is now another way out – through the bridge.

Creating these Lightning bridges (unlike in many other projects and cross-chain bridges) is completely trustless, decentralized and there is a competitive market for it – bridge operators compete on fees and liquidity.

How does it work in practice?

The bridge is trustless, because for both sides it is just a lightning channel. So it is trustless the same way normal lightning payment routing is trustless. It has to be operated by the same entity, because the bridge is not backed by coins, but both paths to and from the bridge are.

Example: Let’s say you are paying a lightning invoice, the path to the recipient node has channels backed by one Bitcoin channel and you yourself have a channel backed by Liquid (BTW: You can have both Liquid and Bitcoin-backed channels and you can partially use both, even for the same payment!). From the point of view of lightning, this is one network (using the same unit of account). Your wallet (“Liquid side”) would create a route. It sees the bridge just as another lightning channel, so if the fees for routing are OK, it will be included in the created route.

When the route is created, the invoice is being paid. The recipient publishes the prehash down the way as normal lightning payment and the HTLCs are slowly removed (because the prehash is revealed), starting from the recipient and going along the path to the sender. As money flows through, the claim (represented by prehash to commited funds) reaches the bitcoin side of the bridge. The channel that constitutes the bridge is not “real” (it is a virtual/hosted channel) and because the funds belong to the same entity, it does not matter how is it split – 0.1BTC/0.2LBTC vs. 0.2BTC/0.1LBTC split does not matter to the operator, because they own both sides, so they are 0.3(L)BTC net worth, split somehow.

After the prehash arrives at the bridge from “Bitcoin side”, meaning someone claimed the payment amount from the bitcoin side of the bridge. In order for the bridge operator to keep their net worth, they will just give the prehash to the other side of the bridge (it’s their node), basically passing it “for free” to the other lightning daemon. And that will use it to claim the precommited amount through the liquid side of the bridge and it’s channel to the liquid part of the network, ultimately being paid by the sender.

  So if Bob is the recipient, the balance of the bridge changes from:

Bob ---->0.1BTC Bridge < virtual channel > 0.2LBTC  ----> Alice

into

Bob ---->0.2BTC Bridge < virtual channel > 0.1LBTC  ----> Alice

Bob is paid, Alice is paying, the balances of BTC vs LBTC side of bridge change, but net amount is the same (actually higher because the routing fees are paid to the bridge).

Conclusion

We have it in our power to expand Lightning network way beyond the Bitcoin timechain. We can allow end-users to make their choices of backing and dispute resolution. We keep most of the properties (limited supply, hard money), empowering users and bringing more value to the network.