To actually solve the problem of receiving funds without having secured liquidity from someone else’s node requires protocol-level changes.
This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
Ignoring the problems of the Lightning Network and protocol stack seems to be a very popular thing to do these days. It is currently the most widely adopted and used second layer of the Bitcoin network, and the fastest moving 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 is very small and at a very early stage of adoption. But that doesn’t make those problems go away, or change the reality that at a much larger scale and further along the adoption curve those problems become very real ones that require actual scalable solutions.
One of the problems at the core of Lightning is the issue of receiving liquidity. It is not possible to receive any funds over the Lightning Network without first having secured receiving liquidity from someone else’s node. This is a fundamental and unavoidable limitation of using the Lightning Network in a non-custodial manner. Obviously, using things like Wallet of Satoshi or Bluewallet’s default LNDHub (which are custodial) you can hack around this problem, but that is only because someone else has solved it for you and you are not actually in control of your funds. When dealing with things self-custodially though, you have to actually address the problem.
When the Lightning Network first went live and began seeing real use during the “#Reckless” era, this problem was addressed very informally. It was essentially solved through social connections; through requests to people you knew or close friends; through handshake agreements “Hey friend, can you send me some liquidity, I just spun my node up.” There were no marketplaces, there were no services to use, it was literally just friends helping each other out. Even today, through things like PLEBNET, a large percentage of the liquidity sourcing occurring on the network is taking place in these kinds 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 that even through indirect degrees of separation are not that far apart from each other. I would say that we are just starting to enter 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 type of arrangement and dynamic is no longer sustainable.
The next phase of growth in solving this problem happened not too long after the network went live. Services like LNBIG began setting up a page where people could request incoming liquidity. Bitrefill began offering channels with receiving liquidity as a service (and in the process created their “Turbo channel” spec which allows you to use a channel even before it’s confirmed on chain). Coincharge, Voltage and many other companies offer similar services as well. Paying a fee, you can simply have a business open a channel with you to provide receiving liquidity in order to be sent money. This step in the evolution of things occurred to solve a sort of scaling problem since not all of the new users coming on board had those social connections to get incoming liquidity. Even if they did, people only have so much money they can allocate to channels for people they know. You can also not expect people to sit around all day, at all times be ready 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 dynamic of lightning service providers (LSPs) like Breez stepping in and themselves providing a certain amount of receiving liquidity for their users. This, however, still runs into the same general problems as sourcing things from people you know: Breez only has so much money they can allocate to their users to receive funds. They do make routing fees by being the node you are connected to, but eventually they will run into the issue of having to manage a finite amount of funds across a growing user base. This isn’t sustainable in perpetuity.
The next type of solution for this core problem of Lightning was actual marketplaces. Not a business selling you their own funds in the form of receiving capacity, but a marketplace where anyone can come and offer to sell receiving liquidity to anyone wishing to purchase it. Two examples of this solution are Lightning Lab’s “Lightning Pool” auction house and Amboss’s Magma marketplaces. Lightning Pool even enforces a minimum length of time the purchased channels must remain open on chain through a CLTV timelock. These are both non-custodial ways for a central party (Lightning Labs and Amboss) to match people wanting to sell with those wanting to buy inbound liquidity. The problem is that they are still dependent on a centralized facilitator to make this work. Lightning Lab’s and Amboss both 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 receiving liquidity built on top of dual-funded channels (where both sides of the channel provide liquidity on funding instead of just one). Liquidity Ads utilizes the Lightning Network’s gossip protocol which advertises public channels available to route payments through in order to publicly post advertisements that you are willing to sell receiving liquidity. Just like Lightning Pool, it also enforces a “lease time” that the channel must remain open for with a CLTV timelock on chain.
So, all of these different options leave one question hanging in the air: how do we really want to approach solving this problem in the long term and at scale? It is literally not possible to receive funds over the Lightning Network without first sourcing receiving liquidity. That is a core limitation of the protocol itself. Do we want to solve this problem at the level of the protocol itself, seeing as that is where the current limitation is, or do we want to lean on centralized services and marketplaces to do so?
When it comes down to it this is a question of network effect, and a chicken-or-egg problem. Buyers want to go where sellers are, but sellers are also going to want to go where buyers are. If we lean hard into centralized marketplaces or services to solve this problem, then eventually that network effect will compound and become more and more difficult to overcome with decentralized protocol-based alternatives. So this is a very important question for users to be asking themselves now. Do we let this massive shortcoming of the Lightning protocol stack be solved entirely by centralized business services, or do we attempt to solve it at the protocol level itself?
Personally, my thinking is that given the need for inbound liquidity is absolutely required to utilize the protocol in a self-custodial way, this problem should be addressed at the protocol level. And as a last note, to solve this at the protocol level in a decentralized way still lets current businesses and centralized solutions compete openly by using that protocol themselves.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
Ignoring the problems of the Lightning Network and protocol stack seems to be a very popular thing to do these days. It is currently the most widely adopted and used second layer of the Bitcoin network, and the fastest moving 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 is very small and at a very early stage of adoption. But that doesn’t make those problems go away, or change the reality that at a much larger scale and further along the adoption curve those problems become very real ones that require actual scalable solutions.
One of the problems at the core of Lightning is the issue of receiving liquidity. It is not possible to receive any funds over the Lightning Network without first having secured receiving liquidity from someone else’s node. This is a fundamental and unavoidable limitation of using the Lightning Network in a non-custodial manner. Obviously, using things like Wallet of Satoshi or Bluewallet’s default LNDHub (which are custodial) you can hack around this problem, but that is only because someone else has solved it for you and you are not actually in control of your funds. When dealing with things self-custodially though, you have to actually address the problem.
When the Lightning Network first went live and began seeing real use during the “#Reckless” era, this problem was addressed very informally. It was essentially solved through social connections; through requests to people you knew or close friends; through handshake agreements “Hey friend, can you send me some liquidity, I just spun my node up.” There were no marketplaces, there were no services to use, it was literally just friends helping each other out. Even today, through things like PLEBNET, a large percentage of the liquidity sourcing occurring on the network is taking place in these kinds 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 that even through indirect degrees of separation are not that far apart from each other. I would say that we are just starting to enter 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 type of arrangement and dynamic is no longer sustainable.
The next phase of growth in solving this problem happened not too long after the network went live. Services like LNBIG began setting up a page where people could request incoming liquidity. Bitrefill began offering channels with receiving liquidity as a service (and in the process created their “Turbo channel” spec which allows you to use a channel even before it’s confirmed on chain). Coincharge, Voltage and many other companies offer similar services as well. Paying a fee, you can simply have a business open a channel with you to provide receiving liquidity in order to be sent money. This step in the evolution of things occurred to solve a sort of scaling problem since not all of the new users coming on board had those social connections to get incoming liquidity. Even if they did, people only have so much money they can allocate to channels for people they know. You can also not expect people to sit around all day, at all times be ready 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 dynamic of lightning service providers (LSPs) like Breez stepping in and themselves providing a certain amount of receiving liquidity for their users. This, however, still runs into the same general problems as sourcing things from people you know: Breez only has so much money they can allocate to their users to receive funds. They do make routing fees by being the node you are connected to, but eventually they will run into the issue of having to manage a finite amount of funds across a growing user base. This isn’t sustainable in perpetuity.
The next type of solution for this core problem of Lightning was actual marketplaces. Not a business selling you their own funds in the form of receiving capacity, but a marketplace where anyone can come and offer to sell receiving liquidity to anyone wishing to purchase it. Two examples of this solution are Lightning Lab’s “Lightning Pool” auction house and Amboss’s Magma marketplaces. Lightning Pool even enforces a minimum length of time the purchased channels must remain open on chain through a CLTV timelock. These are both non-custodial ways for a central party (Lightning Labs and Amboss) to match people wanting to sell with those wanting to buy inbound liquidity. The problem is that they are still dependent on a centralized facilitator to make this work. Lightning Lab’s and Amboss both 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 receiving liquidity built on top of dual-funded channels (where both sides of the channel provide liquidity on funding instead of just one). Liquidity Ads utilizes the Lightning Network’s gossip protocol which advertises public channels available to route payments through in order to publicly post advertisements that you are willing to sell receiving liquidity. Just like Lightning Pool, it also enforces a “lease time” that the channel must remain open for with a CLTV timelock on chain.
So, all of these different options leave one question hanging in the air: how do we really want to approach solving this problem in the long term and at scale? It is literally not possible to receive funds over the Lightning Network without first sourcing receiving liquidity. That is a core limitation of the protocol itself. Do we want to solve this problem at the level of the protocol itself, seeing as that is where the current limitation is, or do we want to lean on centralized services and marketplaces to do so?
When it comes down to it this is a question of network effect, and a chicken-or-egg problem. Buyers want to go where sellers are, but sellers are also going to want to go where buyers are. If we lean hard into centralized marketplaces or services to solve this problem, then eventually that network effect will compound and become more and more difficult to overcome with decentralized protocol-based alternatives. So this is a very important question for users to be asking themselves now. Do we let this massive shortcoming of the Lightning protocol stack be solved entirely by centralized business services, or do we attempt to solve it at the protocol level itself?
Personally, my thinking is that given the need for inbound liquidity is absolutely required to utilize the protocol in a self-custodial way, this problem should be addressed at the protocol level. And as a last note, to solve this at the protocol level in a decentralized way still lets current businesses and centralized solutions compete openly by using that protocol themselves.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
Feedzy
