In the last couple of weeks, many people in the Bitcoin community have been talking about inbound capacity in the Lightning Network. The increasing difficulty to receive the Lightning Torch together with Bitrefill’s launch of Thor and LND’s release of Lightning Loop have led people to become more aware of it. In this post, we explain what it is and why it originates. We also share some insights that are easy to miss at first glance.
Local and Remote Balance
The need for inbound capacity can only be understood by taking a closer look at the Lightning Network’s first building block: payment channels. You have probably heard of them before, so let’s jump directly to the aspects that are related to inbound capacity.
We’ll first think of one channel separately, and increase the complexity of the setup throughout the post.
While a payment channel is open, there is a constant amount of bitcoins locked in it. This is called the channel capacity. Both sides of the channel own a portion of its capacity. The amount on your side of the channel is called local balance and the amount on your peer’s side is called remote balance. Your local and remote balance can be updated many times without closing the channel, but the channel capacity cannot change without closing (or splicing) it.
Every time you make a payment, you push part of your local balance to your peer. This decreases your local balance and increases your remote balance. Similarly, when you receive a payment, your local balance increases in the same amount your remote balance decreases.
Inbound and Outbound Capacity
Now that we have a clearer understanding of what determines the capacity of a channel and how the local and remote balance update, let’s think of what happens when you are part of a network of connected nodes.
Two peers don’t need to be directly connected to pay each other. Instead, they can pay through routing nodes. In each hop a payment does, there’s always a two-sided payment channel under the hood. Therefore, what we have just seen for one payment channel applies in each hop.
Let’s suppose you want to sell stickers via the Lightning Network. Therefore, you need to connect to at least one node of the Lightning Network. You choose it carefully, making sure it’s connected to your potential customers, Sophie and Angela. Let’s call this node lnTop.
Now, Angela wants to buy you some stickers and pay you via lnTop. But, your remote balance with lnTop is 0 and lnTop cannot send you money. LnTop cannot route the payment.
At a given moment, the amount of money you can receive, or inbound capacity, is limited by your remote balance. You simply cannot receive more money than what your adjacent nodes can send you. Similarly, the amount of money you can send, or outbound capacity, is limited by your local balance.
When you opened a channel with lnTop, you decided how much bitcoins you wanted to lock in it, i.e. your initial local balance. Similarly, if lnTop opens a channel with you, they will determine your initial remote balance. This has important implications. While choosing your initial local balance allowed you to decide your initial outbound capacity, you had no control over your initial remote balance or inbound capacity.
If you launch your Lightning node today, and simply open a channel to another node of your choice, you will probably figure out you have no inbound capacity, i.e. you cannot receive payments via the Lightning Network. Seems like a huge problem for merchants, right?
The good news is that there are several ways to increase your inbound capacity, from simply spending money to asking (and paying) other nodes to provide it. This postexplores different solutions to the inbound capacity problem.
So, is that it?
Well… no, it’s not. Even if you figure out how to get enough remote balance on your channel with lnTop, the problem of inbound capacity might not be solved. Here’s the thing: not all inbound capacity is the same. To understand the reasons for this, we need to have more information of what’s happening in the rest of the network. Let’s reveal the local and remote balances of all nodes in the network to better understand how money flows.
After gaining some inbound capacity with lnTop, Angela can send you up to 2 BTC because you have at least 2 BTC of remote balance with lnTop, and lnTop has at least 2 BTC of remote balance with Angela.
However, in this network, Sophie cannot even send you 1 BTC. If you take a look at the route between Sophie and you, you will see that in spite of you having 3 BTC as remote balance, lnTop doesn’t have inbound capacity with lnFirst.
For incoming payments, each routing node and you (the receiver) need to have enough inbound capacity with the previous, adjacent node. So, while you might have solved inbound capacity with your adjacent node, lnTop, lnTop might not have good inbound capacity with their adjacent nodes. Alex Bosworth, Lightning Infrastructure Lead at Lightning Labs pointed this out some weeks ago (item 6)
There’s another fact that makes the situation a harder to solve. This thing of “revealing the local and remote balances of all nodes”, cannot be done in the Lightning Network. As a node of a network, you only get to know channels’ capacity, but not how it is distributed between the two peers.
Who is affected by this problem?
In the Lightning Network, not all nodes are equal or have the same needs. Looking at our example, we can identify at least three types of nodes.
- Merchant nodes
We’ll call merchant nodes to those who are primarily receiving money in the Lightning Network. In the example above, you would be a merchant node because you are mostly interested in getting paid for the stickers you sell. For it, you need to have inbound capacity. Remember: not just with your adjacent node, but all the way from your customers to you.
- End users nodes
These nodes are mainly sending money via the Lightning Network. Occasionally they could also receive money from friends or Lapps. Sophie and Angela would be end users. For this set of users, it is key to connect to other nodes with well-funded routes to merchants. They need both, inbound and outbound capacity, dependent on their behaviour.
- Routing nodes
These nodes are routing payments through the network and charging a fee for it. LnTop and lnFirst are some examples. Their job is to detect relevant destinations, like you, the biggest sticker merchant in town. They need inbound capacity upstream with end users, and outbound capacity downstream with merchants. Also their fees have to be competitive with the rest of the market and they need to make sure to be online. Tough job, right?
Conclusion
We have discussed about inbound capacity starting by a single payment channel, then understanding the channel within a network and finally gaining full information of the other nodes.
We defined inbound capacity as the amount of money you can receive via the Lightning Network at a given moment and understood how it is dependent on your remote balance.
The inbound capacity problem seems to be a bootstrapping problem of the Lightning Network. As such, it might be less relevant once there’s more and better distributed liquidity in the network. We’ll keep writing about relevant aspects of the Lightning Network in its early days.
