This is a Shinobi opinion writer, self-taught educator in the bitcoin space and tech-oriented bitcoin podcast host.
Ignoring problems with the Lightning Network and protocol stack seems to be very popular these days. It is currently the second most accepted and used layer of the Bitcoin network, and the fastest progress in terms of further development. It also has many shortcomings that are easy to sweep under the rug and roll back as it is very small and in a very early stage of adoption. But that doesn’t make those problems go away or change the reality that on a much larger scale and further down the adoption curve, those problems become very real problems that become real scalable solutions.
One of Lightning’s key points is the issue of receiving cash. It is not possible to receive money 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-preservative way. With things like Wallet or Satoshi or Bluewallet’s default LNDHub (which are custodians) you can of course disable this problem, but that’s only because someone else solved it for you and you don’t really have control over your money. But when you do things alone, you actually have to solve the problem.
When the Lightning Network first went live and started seeing real-world usage in the “#Reckless” era, this issue was resolved very informally. It was mainly resolved through social relations; through solicitations to people you know or close friends; by handshake agreements “Hey my friend can you send me some money, I just tied my knot”. There were no markets, no services to use, it was literally just friends training. Even today, thanks to things like PLEBNET, a large percentage of the network’s liquidity supply is in these kinds of informal social arrangements.
The network is still very small and still limited to what, on a social graph, is a small set of actors who, even by indirect degrees of separation, are not that far apart. I would say that we are only now entering a growth phase where the size of the network and the number of open people are getting to the point where this kind of setup and dynamic is no longer sustainable.
The next growth phase in solving this problem occurred shortly after the network went live. Services like LNBIG started creating a page where people could request incoming money. Bitrefill started offering channels of receiving cash as a service (thereby creating the “Turbo Channel” specification that allows you to use a channel even before it’s 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 receive cash to receive money. This step in the evolution of things happened to solve some sort of scaling problem as not all new onboard users had these social logins to get inbound liquidity. Even if they do, people only have a limited amount of money to allocate to channels for people they know. You also can’t expect people to hang out all day, always ready to open channels when people need cash. For example, a company has the option to intervene against payment and solve the problem.
You also have the dynamism of Lightning Service Providers (LSPs) like Breez stepping in and providing a certain amount of received liquidity to their users themselves. However, this still encounters the same general problems as buying from people you know: Breez only has an amount of money that it can allocate to its users to receive money. They charge a routing fee because they are the node you are connected to, but eventually they will run into the problem of having to manage a limited number of funds on a growing user base. It cannot be kept forever.
The next type of solution to this core Lightning problem was the actual marketplaces. This is not a company that sells its own money to you in the form of receiving capacity, but a marketplace where anyone can come and offer to sell cash or perhaps buy some. 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 that purchased channels must remain open on the channel through a CLTV time slot. These are two non-custodial ways for a central party (Lightning Labs and Amboss) to match people who want to sell with those who want to buy inbound liquidity. The problem is, 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 embedded on top of dual-funded channels (where both sides of the channel provide liquidity on funding rather than just one). Liquidity Ads uses the Lightning Network gossip protocol that advertises available public channels to route payments to the public posting of ads you are willing to sell in order to receive cash. Like Lightning Pool, it also enforces a “localize duration” where the channel must remain open with a CLTV timeslot on the channel.
So all these different options leave one question unanswered: how do we really want to tackle this long-standing, large-scale problem? It’s literal Not possible to receive money on the Lightning Network without having to borrow money first. This is an essential limitation of the protocol itself. Do we want to tackle this problem at the protocol level itself, as that is the current limitation, or do we want to fall back on centralized services and marketplaces?
Ultimately it is a question of network effect and a chicken-or-egg problem. Buyers want to go where the sellers are, but sellers 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 right now. Are we going to solve this huge hole in the Lightning protocol stack entirely by centralized business services, or are we trying to solve it at the protocol level itself?
Personally, I think that since the need for inbound liquidity is absolutely necessary to run the protocol autonomously, this problem should be solved at the protocol level. And as a final note, by solving this problem at the protocol level in a decentralized way, current companies and centralized solutions can still openly compete with this protocol itself.
This is a guest post from Shinobi. The opinions expressed are entirely their own and do not necessarily relate to those of BTC Inc or Bitcoin Magazine†