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