A Problem With Bitcoin’s Lightning Network Liquidity and Ideas to Fix It

0

To really solve the problem of receiving funds without having obtained liquidity from someone else’s node requires changes at the protocol level.

This is an opinion piece by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.

Ignoring Lightning Network and protocol stack issues seems like a very popular thing to do these days. It is currently the second most widely adopted and used layer of the Bitcoin network, and the fastest progression in terms of further development. It also has a lot of shortcomings that are easy to sweep under the rug and work around, given that it’s very small and at a very early stage of adoption. But that doesn’t make these issues go away or change the reality that on a much larger scale and further down the adoption curve, these issues become very real problems that require real scalable solutions.

One of the issues at the core of Lightning is the issue of receiving cash. It is not possible to receive funds on the Lightning Network without first securing the receipt of cash from someone else’s node. This is a fundamental and unavoidable limitation of using the Lightning Network in a non-custodial fashion. Obviously using things like Wallet of Satoshi or Bluewallet’s default LNDHub (which are custodians) you can get around this problem, but that’s only because someone else solved it for you and that you don’t actually control your funds. However, when you deal with things on your own, you actually have to solve the problem.

When the Lightning Network first went live and started to see real-world use in the “#Reckless” era, this problem was solved very informally. It was essentially resolved through social relations; through requests to people you know or close friends; through handshake agreements “Hey my friend, can you send me some cash, I just created my knot.” There were no markets, there were no services to use, it was literally just friends helping each other. Even today, through things like PLEBNETa large percentage of the liquidity supply on the network takes place in these types of informal social arrangements.

The network is still very small and still confined to what, on a social graph, is a small set of actors who, even by indirect degrees of separation, are not so far apart. I would say that we are just beginning to enter a growth phase today where the size of the network and the number of people involved are starting to get to the point where this type of arrangement and dynamic is no longer sustainable.

The next phase of growth in solving this problem occurred shortly after the network went live. Services like LNBIG started creating a page where people could request incoming cash. Bitrefill started offering channels with receiving cash as a service (and in the process created its “Turbo channel” specification which allows you to use a channel even before it is confirmed on the channel). Coincharge, Voltage and many other companies also offer similar services. By paying a fee, you can simply ask a company to open a channel with you to provide receive cash to receive money. This evolutionary step happened to solve some kind of scaling problem since not all new users on board had these social logins to get incoming liquidity. Even if they did, people only have a limited amount of money they can allocate to channels for people they know. You also cannot expect people to sit around all day, be ready at all times to open channels when people need cash. Thus, a company has the opportunity to step in and fix the problem for a fee.

You also have the dynamic of Lightning Service Providers (LSPs) like Breez stepping in and providing a certain amount of receive liquidity themselves for their users. This, however, still comes up against the same general issues as sourcing from people you know: Breez only has an amount of money it can allocate to its users to receive funds. They charge routing fees by being the node you are connected to, but eventually they will run into the problem of having to manage a limited amount of funds on a growing user base. It is not sustainable in perpetuity.

The next type of solution for this core Lightning problem was real marketplaces. This is not a company that sells you its own funds in the form of receive capacity, but a marketplace where anyone can come and offer to sell receive cash to anyone who wants to buy it. Two examples of this solution are Lightning Lab’s “Lightning Pool” auction house and Amboss’ Magma marketplaces. Lightning Pool even imposes a minimum amount of time purchased channels must remain open on the channel through a CLTV time lock. These are two non-custodial ways for a central party (Lightning Labs and Amboss) to match people wanting to sell with those wanting to buy incoming liquidity. The problem is that they still depend on a centralized facilitator to make it work. Lightning Lab’s and Amboss both charge a fee to participate in their auctions.

A final category of solutions to this problem is embodied by CLN liquidity announcements, a decentralized marketplace for receiving liquidity built on top of dual-funded channels (where both sides of the channel provide liquidity on funding instead of only one). Liquidity Ads uses the Lightning Network gossip protocol that advertises available public channels to route payments to publicly post ads that you are willing to sell to receive cash. Just like Lightning Pool, it also enforces a “rental duration” where the channel must remain open with a CLTV timelock on the channel.

So, all of these different options leave one question unanswered: how do we really want to approach solving this long-term, large-scale problem? It’s literally Not possible to receive funds on the Lightning Network without having to first source to receive cash. This is an essential limitation of the protocol itself. Do we want to solve this problem at the level of the protocol itself, since that is where the current limitation is, or do we want to rely on centralized services and marketplaces to do so?

Ultimately, it’s a matter of network effect and a chicken or egg problem. Buyers want to go where the sellers are, but sellers will also want to go where the buyers are. If we rely heavily on centralized marketplaces or services to solve this problem, this network effect will eventually worsen and become increasingly difficult to overcome with decentralized protocol-based alternatives. So this is a very important question that users need to ask now. Do we let this huge gap in the Lightning protocol stack be solved entirely by centralized business services, or do we try to solve it at the level of the protocol itself?

Personally, I think that since the need for incoming liquidity is absolutely necessary to use the protocol autonomously, this problem should be solved at the protocol level. And as a final note, solving this problem at the protocol level in a decentralized way still allows current companies and centralized solutions to compete openly using this protocol themselves.

This is a guest post from Shinobi. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or bitcoin magazine.

The views and opinions expressed herein are the views and opinions of the author and do not necessarily reflect those of Nasdaq, Inc.

Share.

Comments are closed.