This is an opinion editor for Shinobi, a self-taught Bitcoin educator and tech-focused Bitcoin podcast host.
Ignoring the problems of the Lightning Network and the protocol stack seems to be a very popular thing these days. It is currently the second most widely adopted and used layer of the Bitcoin network and is the fastest moving layer in terms of further development. It also has many flaws that are easy to swept under the rug and work on given that it’s so small and at a very early stage of adoption. But that doesn’t eliminate these issues or change the fact that on a much larger scale and along the adoption curve these issues have become very real issues that require truly scalable solutions.
One of the problems at the core of Lightning is the problem of getting liquidity. It is not possible to receive any funds over the Lightning Network without first guaranteeing liquidity from someone else’s node. This is a fundamental and unavoidable limitation of using the Lightning Network unattended. Obviously you can get around this by using things like Satoshi Wallet or Bluewallet’s default LNDHub (which is a custodian), but it’s only because someone else has fixed the problem for you and you’re not actually in control of your money. That said, when you’re dealing with things under personal supervision, you really need to tackle the problem.
This issue was addressed very informally when the Lightning Network first went live and began to see real use in the “#Reckless” era. Mainly solved through social connections; through requests made to acquaintances or close friends; via handshake deals “Hey man, can you send me some liquidity, I just flipped my knot.” There were no marketplaces, no services to use, literally just friends helping each other. Even today, through things like PLEBNET, a large percentage of the liquidity resources that occur in the network take place in such informal social arrangements.
The network is still very small and still confined to a small group of actors on a social graph, not so far apart even through indirect degrees of separation. I would say we are just entering a phase of growth today where the size of the network and the number of people involved are starting to get to the point where this kind of regulation and dynamic is no longer sustainable.
The next growth stage in solving this problem came shortly after the network went live. Services like LNBIG have started creating a page where people can request inbound liquidity. Bitrefill began offering channels that receive liquidity as a service (and in the process created “Turbo channel” features that allow you to use a channel even before it is approved on the chain). Coincharge, Voltage and many other companies also offer similar services. By paying a fee, you can have a business open a channel with you to ensure that liquidity is received for sending money. This step in the evolution of things happened to solve some kind of scaling issue because not all new users who came aboard had these social connections to get the incoming liquidity. Even if they do, people have enough money to channel just because they know. Nor can you expect people to always be ready to open channels when they need liquidity, to sit and wait all day. Therefore, a business has room to address and fix the problem for a fee.
You also have the dynamics for lightning service providers (LSPs) like Breez to step in and provide a certain amount of liquidity to their users. However, this still faces the same general problems as sourcing things from people you know: Breez has enough money for its users to allocate to receive funds. They charge referral fees as the node you connect to, but will eventually have to manage a limited amount of funds in a growing user base. This is not sustainable forever.
The next type of solution for this core problem of Lightning was real marketplaces. Not a business that sells its own funds to you in the form of buying capacity, but a marketplace where anyone can come and offer to sell the buyer liquidity to anyone willing to buy it. Two examples of this solution are Lightning Lab’s “Lightning Pool” auction house and Amboss’ Magma marketplaces. Lightning Pool even mandates the minimum amount of time purchased channels must remain open on the chain via a CLTV timelock. Both of these are unattended methods for a central party (Lightning Labs and Amboss) to match those who want to buy incoming liquidity with people who want to sell. The problem is, they still depend on a central facilitator to get this job done. Lightning Lab’s and Amboss actually charge a fee for participating in their auctions.
A final category of solutions to this problem is embodied by CLN’s Liquidity Ads, a decentralized marketplace of dual fund channels for buying liquidity (where both sides of the channel provide liquidity rather than a single channel). Liquidity Ads uses the Lightning Network’s gossip protocol to introduce public channels that can be used to direct payments to publicly run ads you want to sell by buying liquidity. As with Lightning Pool, it also imposes a “lease period” during which the channel must remain open with an on-chain CLTV time lock.
So all these different options leave a hanging question: How do we really want to approach solving this problem in the long term and at scale? literally not possible Receive money over the Lightning Network without the need to buy liquidity first. This is a fundamental limitation of the protocol itself. Do we want to solve this problem at the level of the protocol itself, seeing where the current limitation is, or do we want to rely on centralized services and markets to do so?
As far as it goes, it’s a net effect issue and a chicken or egg issue. Buyers want to go where the sellers are, but sellers will want to go where the buyers are. If we cling to centralized markets or services to solve this problem, eventually this network effect will converge and it will become increasingly difficult to overcome with decentralized protocol-based alternatives. So this is a very important question that users should be asking themselves now. Are we going to allow this major shortcoming of the Lightning protocol stack to be solved entirely by central business services, or are we trying to solve it at the protocol level itself?
Personally, my opinion is that this question should be addressed at the protocol level, given that the incoming need for liquidity is absolutely necessary to use the protocol in its self-storage way. And as a final note, solving this at the protocol level decentralized allows existing businesses and centralized solutions to compete openly using this protocol themselves.
This is Shinobi’s guest post. The opinions expressed are their own and are not their own and BTC Inc. or Bitcoin Magazine.