Site icon Juraj Bednar

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

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. In this block I want to build a case for expanding the Lightning network beyond the bloated Bitcoin time-chain, 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).

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.

Using Liquid to expand Lightning

An obvious and super easy way would be to use the Liquid side-chain. 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 much better than 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.

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 automatically”. 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 Bitcoin coffee!

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 customer 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 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.

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 multisig, because there is now another way out – through the bridge.

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

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.

Exit mobile version
Skip to toolbar