This is an opinion editorial from Shinobi, a self-taught teacher in the bitcoin space and tech-oriented bitcoin podcast host.
Ignoring the Lightning Network and protocol stack problems is a very popular thing to do these days. It is currently the most widely adopted and used second layer of the bitcoin network, and one of the fastest in terms of further development. It also has a number of drawbacks that are easy to sweep under the rug and work around, given that it is very small and in the very early stages of adoption. But that doesn’t remove those problems, or change the reality that as mass-and-further adoption curves, those problems become too real to require real scalable solutions.
One of the problems at the core of Lightning is the issue of obtaining liquidity. It is not possible to receive any funds on the Lightning Network without first securing liquidity from someone else’s node. This is a fundamental and inevitable limitation of using the Lightning Network in a non-custodial manner. Obviously, you can solve this problem by using things like Wallet of Satoshi or BlueWallet’s default LNDHub (which are custodial), but that’s only because someone else solved it for you and you really Are not in control of their funds. However, when dealing with self-custodial things, you have to actually address the problem.
When the Lightning Network first went live and began to see actual usage during the “#reckless” era, the problem was addressed very informally. This was essentially resolved through social interactions; through requests from people you knew or were close friends with; Via handshake agreement “Hey friend, can you send me some liquidity, I just expanded my node.” There was no market, no service to use, it was literally just friends helping each other. Even today, a large percentage of the liquidity sourcing that happens on the network is happening in these types of informal social systems, through things like the PLEBNET.
The network is still very small, and is still a small group of actors on a social graph that is not too far from each other, even through an indirect degree of isolation. I would say that we are starting to enter a phase of growth today where the size of the network and the number of people involved are starting to reach the point where this type of arrangement and dynamic is no longer sustainable.
The next stage of development in solving this problem occurred not long after the network went live. Services like LNBIG began creating a page where people could request incoming liquidity. Bitrefill began offering liquidity-seeking channels as a service (and in the process created their “Turbo Channel” device which allows you to access a channel even before it is confirmed on-chain). Coincharge, Voltage and many other companies also provide similar services. Paying the fee, you can open a business simply to open a channel with you to get the liquidity to send money. This move in the development of things happened to solve a sort of scaling problem because not all the new users on board had the social connections they needed to get the liquidity that was coming. Even if they did, people have only enough money to allocate channels for people they know. You also cannot expect people to sit all day, ready all the time to open channels when people need liquidity. So, a business has room to step in and solve the problem for a fee.
You also have the mobility of Electricity Service Providers (LSPs) like Breeze and they are getting a certain amount of liquidity for their users. However, it still runs into the same general problems as getting things from people you know: Breeze only has so much money they can allocate to getting the money out to their users. The nodes you connect to make up the routing fee, but they will eventually run into the issue of managing a limited amount of money on a growing user base. It is not permanently sustainable.
The next solution to this major power problem was the real market. It’s not a business that sells you the ability to get your own money, but rather a marketplace where anyone can come and offer to get liquidity to anyone willing to buy it. Two examples of this solution are Lightning Lab’s “Lightning Pool” auction house and Emboss’s Magma Marketplace. Lightning Pool also enforces a minimum on-chain period for channels purchased via CLTV Timelock to remain open. These are both non-custodial methods for the central party (Lightning Labs and Emboss) to match those willing to sell with those willing to buy inbound liquidity. The problem is that they still rely on a centralized facilitator to make this work. Both Lightning Lab and Emboss actually charge a fee to participate in their auctions.
A final category of solutions to this problem is embodied by CLN’s Liquidity Ads, a decentralized marketplace for obtaining liquidity built on top of dual-funded channels (where both sides of the channel provide liquidity on funds rather than just one). Huh). Liquidity Ads use the Lightning Network’s gossip protocol, which advertises public channels available to pay you for posting ads that you are willing to sell to the liquidity you receive. Like Lightning Pool, it also enforces a “lease time” that requires the channel to remain open on-chain with a CLTV timelock.
So, all these different options leave one question hanging in the air: How exactly do we want to solve this problem long term and on a large scale? it’s literal not possible To receive funds on the Lightning Network without first obtaining liquidity. This is the main limitation of the protocol itself. Do we want to solve this problem at the protocol level, given that the current limitation lies here, or do we want to rely on centralized services and markets to do so?
When it comes down to it it’s a question of network effects 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 work hard in centralized markets or services to solve this problem, eventually the network effect will become more and more complex with decentralized protocol-based alternatives. So this is a very important question for the users who are asking themselves now. Do we allow this massive shortcoming of the Lightning protocol stack to be solved entirely by centralized business services, or do we try to solve it at the protocol level itself?
Personally, my thinking is that given the need for inbound liquidity that needs to be used in self-custodial use of the protocol, this problem should be addressed at the protocol level. And as a final note, solving this in a decentralized manner at the protocol level still lets current businesses and centralized solutions using that protocol compete openly.
This is a guest post by Shinobi. The opinions expressed are solely their own and do not necessarily represent those of BTC Inc. or . reflect the thoughts of bitcoin magazine,