Unbacked Lightning channels proposal – how to scale, increase capital efficiency and interoperability of Lightning

I believe in order to improve lightning network, we should allow for unbacked channels between nodes of the same owners (operators). It would enable a few very interesting use-cases, without causing inflation or any other risk to other parts of the network.

Unbacked channels increase capital efficiency, availability and help in growing the network by off-loading the fees for new users’ channels to a sidechain – while keeping Lightning one large network. Read more for all the use-cases, risks and details.

The proposal

The idea is simple – specified protocol to allow two nodes to mutually create an “infinite” channel that is not backed by any UTXO, does not have funding transaction, there are no commitment transactions and closing the channel is simply revoking the permission. The channel just passes hashes around to enable payments.

Who would use it

Before adding features to Lightning, I believe it is smart to consider use-cases and categories of users first. There are so many things that could be built, but not many things that should be built. I believe unbacked lightning channels should exist. Let me tell you about the main use-cases I see right now.

Operators of multiple nodes

The usage is strictly among nodes that belong to the same owner. This owner does not care which node holds the balance. An example could be a channel liquidity provider that provides good LN connectivity using multiple nodes – like LNBIG. Before this proposal, they would need to create a channels among their own nodes, unnecessarily locking coins and accounting among nodes.

Gateways between (side)chains – onboarding users on Liquid, paying on Bitcoin via Liquid to Bitcoin Lightning bridge

We cannot onboard everyone to lightning using the Bitcoin blockchain. There simply is not enough blockspace. With future innovations like channel factories, or channel open batching, there might be some more space, but still not for everyone. There are of course custodial wallets that do not open channels for everyone, but… they are custodial. We have a nice sidechain solutions like Liquid (which is operated by blockstream).

If you use confidential transactions, which hide the amounts, the per-hour transaction capacity is approximately double (accounting for larger transactions) than Bitcoin blockchain. But that means all transactions that happen on Liquid don’t need to happen on Bitcoin blockchain.

Also, Liquid blocks are almost empty and are more frequent (Liquid has deterministic 1 minute blocks). So for 0.1 sat/vB, you can get a channel confirmed in two minutes (which is Liquid’s finality).

Now it gets interesting. The unit of account of both Bitcoin and Liquid is Bitcoin. So theoretically, Lightning can use both networks and route among them. There is already a working implementation of clightning for Liquid.

So image onboarding users with fast and cheap channels and allowing them to pay any Bitcoin Lightning invoice, without any kind of exchange rate risk. What is required to do this? You guessed it – unbacked channels. In order for this to work, you have to bridge Bitcoin’s and Liquid’s lightning networks. But you cannot do that easily with backed channels, because the founding transation is 2-of-2 multisig representing both sides of the channel – and this multisig is on one chain.

If someone would like to create a bridge, they would need to run clightning on Liquid, some lightning daemon (possibly also clightning) on Bitcoin and create a trusted unbacked channel. Then they set routing fees, which account for the fact that this bridge would be changing L-BTC to BTC and vice versa (without exchange rate risk, but there are transaction fees).

Now I might hear people talking about decentralization and how they don’t like Liquid. The nice thing about this solution is – you don’t have to like Liquid. If you open channels on Bitcoin blockchain, you gain liquidity of Liquid Lightning users without being exposed to the risk of Liquid. Your channels are represented by UTXOs you agree with – on a chain that you chose. So if you are a store running BTCPayserver and you would like to get paid via Lightning on Bitcoin chain, just open channels as usual. The coins get magically converted by a bridge from L-BTC to BTC on the way. No additional risk for you.

Yet, you gain access to the payment network of possible users, who chose faster, cheaper and confidential transactions, while giving away a bit of decentralization. And the unit of account is still Bitcoin.

This would also make it easier to change from BTC to L-BTC and vise versa. Just open a channel and pay yourself. You pay market fees, determined by the bridges on your path. Currently, it is not as easy to switch between BTC or L-BTC. You have to register to an exchange or lose custody for a while – or pay hefty fees for multisig peg-in / peg-out mechanism.

Use multiple daemon implementations

So you like to use Zap wallet on your iPhone with your lnd lightning node. But on the server, you like to use Lightning Charge, which works on top of c-lightning. What do you do? You install both lnd and c-lightning, make sure you have safe backups for both nodes, lock some of your capital to directly connect your lnd and your c-lightning together and open some channels.

With unbacked channels, this is completely unnecessary. You install lnd, open only one unbacked channel to your c-lightning that shows the whole send and receive capacity of your c-lightning node (so your Zap wallet displays correct balances). You open channels on your c-lightning node and make sure you back it up. In case of a problem with lnd, you can safely delete it – there are no funds on it (unless you receive an onchain transaction or open a channel directly to your lnd).

You can use front-end for one wallet, using cool features like turbo channels of Eclair.

While it would be nice if all major Lightning node implementations had a unified RPC API, I guess at this point in development of lightning, it is better if we let the implementations innovate on their own and standardize only on the protocol level. Creating unbacked channels solves this problem in a unique way – you can run all node implementations independently, while maintaining one set of channels.


There are no risks known to me to other users. The lightning network keeps all its properties. Payment channels are still backed by UTXOs on a chosen chain, it is still a trustless network.

There are however risks and we should consider them before implementing this feature.

First of all, the process of opening an unbacked channel should be difficult, with all the warnings – I would not like to see scams tricking people into opening unbacked channels. It should not be possible with QR codes, one liners or a simple click in a GUI wallet. People need to understand what they are doing. An interactive prompt requiring to type something like: “I understand that I am opening an unbacked channel and if the second node does not fully belong to me, I will lose funds. By typing this, I understand what I am doing.” Yes, you can require such a paragraph, written by the user.

The second problem is that hack of one node basically means hacking them all. By constructing routes through the nodes, you can steal all money from all nodes, even if you got access only to one. For this, I highly recommend making an option of making the unbacked channel unidirectional. For example BTCPayserver’s lightning node can be configured to only allow receiving through the unbacked channel. This adds liquidity of your other nodes, but will not allow sending funds out through this channel. If this is the only channel, this adds additional benefit that hacking BTCPayserver’s lightning node does not allow you to steal any funds – there are no funds, all the funds are on the other side of the unbacked channel. This could actually help security a bit, because BTCPayserver and it’s Lightning node are more tightly integrated and there is a larger attack surface (although BTCPayserver is quite well designed and services are segregated in the dockerized setup – I love BTCPayserver!).


Unbacked channel bring expansion of possibilities of all lightning implementations without the necessary costs of opening channels, possibility for higher liquidity and high availability, less frozen capital, bridge between chains (while allowing users to choose which [side]chain they trust) and easier onboarding of users, while not introducing any complexity for merchants.

Unbacked channels need to be consensual among nodes belonging to the same entity that does not need any kind of inter-node accounting. Balance on one node is the same as balance on other node to them.

I wanted to call them “infinite unbacked channels”, but they actually have capacity limit – which is the sending and receiving capacity of the node on the other side. This should be reflected in the channel and it should be seen by the nodes that way. It should be also possible to configure the channel as unidirectional.

I write this blog as an introductory proposal for lightning network improvement. I believe it needs protocol work on the network level to negotiate the channels. And they should be universal (not per lightning implementation), but if possible, supported as a plug-in that has to be installed extra.

Existing work

It seems that here is a proposal called hosted channels. The reasoning behind it is a bit different, but at first look, most of what I wanted to do would be doable under this proposal. I am trying to see if there are any node implementations.

Learn more

I previously wrote about ways that Bitcoin network could be censored. Here’s part one and part two.

I made a course about how to settle small debts among friends and family and use Lightning network to pay through non-KYC exchanges. If you have never tried Lightning network and don’t know where to start, this might be a good start. Open channels when fees are low, you can thank me later.

I also produce a podcast dedicated to increasing our options, thus increasing our freedom. It’s called Option Plus Podcast. There are episodes about opting out, strategies for being more free here and now. If you want to learn more about strategy of parallel societies, I recommend a Cypherpunk Bitstream episode, where Smuggler and Frank invited me and Martin to talk about Parallel Polis – a strategy to achieve more liberty in a communist dictatorship of former communist Czechoslovakia. Yes, we can use this strategy today.

If you want to learn more about financial surveillance and how it applies to crypto – and especially how it is made and enforced outside of parliaments and governments, check out my talk from HCPP on Financial Surveillance and Crypto Utopias.

You can also follow me on Twitter @jurbed.

Leave a Reply

Your email address will not be published. Required fields are marked *

You can encrypt your comment so that only juraj can read it.