For several weeks, many people in the Bitcoin community have been discussing the inbound capacity of the Lightning Network. It is becoming more and more difficult to receive the lightning torch, Bitrefill has launched Thor, and LND has released the Lightning Loop, which makes people pay more attention to this issue. In this article, I will explain the form of this problem and its root cause.
We will also share some insights that are easily overlooked.
Local and remote balances
To understand the accounted capacity, we must first understand the first basic module of the Lightning Network: the payment channel. You may have heard this concept before, so we jump directly to the part related to the accounted capacity.
We first consider a single channel, and then slowly increase the complexity of thinking.
After a payment channel is opened, it locks a constant amount of btc. This amount is called “channel capacity”. Both parties participating in the payment channel each own a portion of this capacity. The balance on your own side is called “local balance”, and the balance on your counterparty side is called “remote balance”. Your local balance and remote balance can be updated any number of times before closing the channel, but the channel capacity cannot be changed if you do not close the channel or splicing the channel.
The payment channel is like an hourglass: although the total amount of sand is constant, you can move the sand to one end at will. But if you want to change the amount of sand in it, you have to break this hourglass
There are 8 btc in your channel with Robert, your local balance is 5 btc, and your remote balance is 3 btc
Every time you pay, you transfer some of your local balance to your counterparty, that is, reduce the local balance and increase the remote balance. Similarly, when you receive a payment, your local balance increases by exactly the amount that your remote balance decreases.
After you paid Robert 1 btc, your remote balance increased by 1 btc
Inbound and outbound capacity
Now, we have a clearer understanding of what determines the capacity of the channel and how the local and remote balances are updated. Now think about the difference if you are a node of the Lightning Network and part of the network.
The two transaction parties do not have a directly connected payment channel. However, they can pay through routing nodes. In the entire payment path, a two-way payment channel is used for each transfer. Therefore, the payment channel feature we just talked about applies to every transfer.
Suppose you want to sell stickers through the Lightning Network. Then, you need to establish a connection with at least one Lightning Network node. You carefully selected a node to ensure that this node may be connected to your potential customers Sophie and Angela. We call this node “lnTop”.
You opened a channel with InTop and locked 2 btc. Your local balance is 2 btc, and your remote balance is 0 btc
Now, Angela wants to buy some of your stickers and pay through lnTop. However, in the channel between you and lnTop, your remote balance is 0, and lnTop cannot pay you. Therefore, lnTop cannot route this transaction.
At a point in time, the amount of btc you can receive (that is, the “accounting capacity”) is determined by your remote balance. It’s very simple. If the node you are connected to can only send you 1 btc, you will not be able to receive a larger amount than 1 btc. Similarly, the amount of btc you can send (“disbursement capacity”) is determined by your local balance.
When you decide to open a channel with lnTop, you need to determine how much btc you want to lock in, that is, what is your initial local balance. The same goes for lnTop, their choice determines your initial remote balance. This has an important impact. Although you can determine your initial local balance (your initial outgoing capacity), you cannot control your own initial remote balance (and incoming capacity).
If you want to start your own Lightning Network node today, and just choose a node to open the channel at random, you may find that you have no credit capacity available at all, that is, you cannot receive it through the Lightning Network at all. Paid. Sounds very unfriendly to businessmen, right?
The good news is that you have many ways to increase your account capacity, such as initiating a payment yourself, or requesting other nodes to provide capacity (and paying them). This article explains different solutions to the problem of credited capacity.
It’s that simple?
Hmm… Nor is it. Even if you know how you can increase your remote balance, you may not be able to solve the problem of credited capacity. The key is: not all channels have the same credit capacity. To understand this, you must first understand what happened to other parts of the Lightning Network during the payment routing process. We have marked out the channel capacity of the network shown in the figure above, so that we can understand it better.
This is the situation after lnTop recharged 3 btc into the channel. In the network, all nodes connected to themselves have special local and remote balances
After you get some credited capacity from lnTop, Angela can only send you 2 btc at most, because your credited capacity at lnTop exceeds 2 btc, but the credited capacity of lnTop at Angela is only 2 btc.
However, in this network, Sophie cannot send you 1 btc. You can look at the channel capacity status on the path Sophie pays you. You do have 3 btc accounted capacity, but lnTop does not have lnFirst accounted capacity. For payment, each node participating in the routing and you (receiver) must keep up with a node and have enough credit capacity. Therefore, although you can solve the problem of the crediting capacity with the neighboring node lnTop, lnTop may not have enough crediting capacity with the neighboring node. Alex Bosworth, Director of Lightning Network Infrastructure at Lightning Labs, pointed out this issue a few weeks ago. There is another fact that makes this problem difficult to solve. That is, “revealing the local and remote balances of all nodes” is impossible on the Lightning Network. As a node in the network, you only know the channel capacity, not how this capacity is distributed between the two participants.
Who will be affected by this problem?
In the Lightning Network, not all nodes have the same needs. From the above example, we can identify at least 3 types of nodes.
Merchant nodes We use “merchant nodes” to refer to those nodes that are mainly collecting accounts. In the above example, “you” is a collection node, because what you care most about is receiving payment from sticker buyers. So you need credit capacity. Remember: Not only do you have to have enough crediting capacity, but the nodes on the entire payment path from the buyer to you must have enough crediting capacity.
End-user nodes These nodes mainly use the Lightning Network to send accounts. Occasionally they will receive money from friends or Lightning apps. Both Sophie and Angela are end users. For this group, the key is to connect nodes with sufficient funds and connected to merchants. They need both in-account capacity and out-of-account capacity, depending on their needs at a specific time.
Routing nodes These nodes are the nodes that route payments and earn commissions from them. Both LnTop and lnFirst are such nodes. Their job is to find recipients in need, such as you, the largest sticker merchant in the town. For end users, they need enough inflow traffic; for merchants, they need outflow capacity. In addition, they have to compete with other service providers in the market to ensure that they are always online. It’s not easy to make some money, right?
We started the discussion with a single channel, explained the characteristics of the channel in the network, and finally discussed the issue of account capacity using the assumption of “full disclosure of node information”. We defined the crediting capacity as the amount of btc you can receive in the Lightning Network at a given point in time, and inferred that it depends on your remote balance. The problem of credited capacity may be a problem encountered during the startup phase of the Lightning Network. Therefore, if liquidity is more fully and better distributed throughout the network, the problem will be alleviated. We will continue to write articles to discuss the problems that the Lightning Network will encounter in the early days.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/explain-the-account-capacity-problem-of-lightning-network-in-detail/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.