Lightning Network: Channels & Liquidity
This page gives an introduction to how the Lightning Network functions under the hood.
The purpose of this document is to explain Lightning Network channels and liquidity principles to help BlockSpaces users to make informed decisions regarding their Bitcoin Invoicing & Payments instances.
The most important thing to understand about the Lightning Network is the concept of a channel. A channel is a payment path between two Lightning nodes. In other words, bitcoin sent over the Lightning Network travels through a channel (or series of channels) to reach its destination. A new channel from a new Lightning node is typically funded using an on-chain Bitcoin transaction.
Channels are looked at and labeled from a liquidity perspective. The simplest way to illustrate how these work is a case of sending one Bitcoin from Lindsay to Lamar. The transaction would be described as an outbound transaction from Lindsay’s perspective, and it would be an inbound transaction from Lamar’s perspective. There is only one channel between them; we just use “inbound” and “outbound” to talk about the direction that funds are traveling. Easy, right?
Channels get a little more complicated when Lindsay wants to pay Lamar without a direct channel between them. In this case, the Bitcoin payment needs to find an indirect path from Lindsay to Lamar through a mutual contact. Let’s say for this example, Lori has channels both to Lindsay and Lamar. In this case the payment would go from Lindsay’s outbound, to Lori’s inbound, then from Lori’s outbound to Lamar’s inbound.
But what if Lori doesn’t have enough Bitcoin to facilitate the transaction? This would mean they don’t have enough liquidity and the transaction would fail, so Lindsay would need to find another path to pay Lamar. Let’s dive a little further into the concept of liquidity in the next section.
Liquidity on the Lightning Network is the ability to send or receive Bitcoin. As with channels we have two different types or liquidity to consider: Inbound liquidity (for receiving payments) and outbound liquidity (for sending payments). Put simply, inbound liquidity is the amount of Bitcoin in a given inbound channel and vice versa for outbound. Outbound liquidity is the amount of Bitcoin in a given outbound channel.
Channel liquidity is measured in BTC or Satoshis (1/100,000,000th of a Bitcoin) and is added/subtracted based on whose perspective we are assuming in the transaction. Say Lindsay and Lori have 1 BTC each on their respective nodes, this means they each have 1 BTC in inbound and outbound liquidity. If Lindsay sends Lori 0.5 BTC, Lindsay’s outbound liquidity is reduced by 0.5 BTC while Lori’s outbound liquidity is increased by 0.5 BTC. Now, Lindsay has 0.5 BTC of outbound liquidity and Lori has 1.5 BTC of outbound liquidity. Interestingly, Lindsay’s inbound liquidity is now raised to 1.5 BTC, and Lori’s inbound liquidity is lowered to .5 BTC The key takeaway here is that Lindsay’s inbound liquidity (ability to receive payments) is a measure of Lori’s outbound liquidity (ability to send payments), and vice versa. Lori’s inbound liquidity (ability to receive payments) is a measure of Lindsay’s outbound liquidity (ability to send payments).
Let’s look at the example image below. Remember when we asked what happens if someone doesn’t have enough liquidity to route a payment? If Lindsay (Green) wants to send a payment of three beads to Larry (Yellow), the payment will fail if Lori (Orange) routes the payment. This is because Lori only has two beads in her channel with Larry, and the beads sent from Lindsay will not go to any other channels. In this instance, the payment will need to route from Lindsay, to Lori, to Lamar (Blue), to Larry.
Liquidity management is a challenge businesses face with taking payments over the Lightning Network. BlockSpaces' Bitcoin Invoicing & Payments offers liquidity management services to abstract these problems away so your business can focus on being a business