Bitcoin | Inbound capacity issues in lightning networks

The inbound capacity of Bitcoin Lightning Network is a good help for you!

Many people in the Bitcoin community have been talking about the inbound capacity of the Lightning Network. In this article, we explain what it is and why it originated. We also shared some insights that are easy to miss.

Local and remote balance

Only by carefully observing the Lightning Network's first building block: the payment channel, can you understand the need for inbound capacity. You may have heard of them before, so let's jump directly to aspects related to inbound capacity.

• Bitcoin's power and difficulty are rising, and high-coin prices are rising, attracting new influx
• Babbitt column | Ren Zhengfei talks about "coin" for the first time, the world has no confidence in the dollar
• Dry goods | Central Bank Digital Currency Events

Although the payment channel is open, it locks a certain amount of bitcoin, which is called channel capacity. Both sides of the channel have some of their capacity. The amount you have on the side of the channel is called the local balance, and the amount you transfer to the other party is called the remote balance. You can update local and remote balances multiple times without shutting down the channel, but you cannot change the channel capacity without closing (or splicing) the channel capacity.

Think of it as an hourglass: although the total amount of sand in it is fixed, you can move it upside down between the upper and lower parts. If you want to change the amount of sand locked in it, you need to break the hourglass.

The channel between you and Robert has a channel capacity of 8 BTCs. Your local balance is 5 BTC and the remote balance is 3 BTC

At each payment, you will need to transfer some of your local balance to your partner. This will lower your local balance and increase your remote balance. Similarly, when you receive a payment, your local balance will increase by the same amount that the remote balance is reduced.

When you pay Robert 1 BTC, your local balance is reduced by 1 BTC and the remote balance is increased by 1 BTC.

Inbound and outbound capacity

Now that we have a clear understanding of the factors that determine channel capacity and how to update local and remote balances, let's think about what happens when you are part of a network of connected nodes.

Two peers do not need to be directly connected to pay each other. Instead, they can pay through the routing node. There is always a bilateral payment channel in every transfer of payment. Therefore, one payment channel we just saw is suitable for every transfer.

Suppose you want to sell stickers through the Lightning Network. Therefore, you need to connect to at least one node of the Lightning Network. Carefully choose and make sure it is associated with your potential customers Sophie and Angela. We call this node lnTop.

You use lnTop to open a channel and lock 2 BTC. Your local balance is 2 BTC and your remote balance is 0 BTC.

Now, Angela wants to buy you some stickers and pay you through lnTop. However, your remote balance with lnTop is 0 and lnTop cannot give you money. LnTop cannot route payments.

At a given moment, the amount or inbound capacity you can get is limited by the remote balance. You simply can't get more money than the money sent to you by neighboring nodes. Similarly, the amount you can send or the outbound capacity is limited by your local balance.

When you open a channel with lnTop, you decide how many bitcoins you want to lock, your initial local balance. Similarly, if lnTop opens a channel with you, they will determine your initial remote balance. This is of great significance. When you select an initial local balance, you can decide on the initial outbound capacity, but you cannot control the initial remote balance or inbound capacity.

If you launch the Lightning node today, simply open a channel to another node of your choice and you may find that you do not have inbound capacity, ie you cannot receive payments via the Lightning Network. It seems to be a huge problem for the business, 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 article explores different solutions to the problem of inbound capacity.

Is that true?

Um… no, no. Even if you figure out how to use lnTop to get enough remote balance on your channel, you may not be able to solve the inbound capacity problem. That's the way it is: not all inbound capacity is the same. To understand why, we need to know more about what happens in other parts of the network. Let us reveal the local and remote balances of all nodes in the network to better understand how funds flow.

This is the network after lnTop funded 3 BTC channels. In the network, each node has local and remote balances with its neighbors.

After getting some inbound capacity with lnTop, Angela can send you up to 2

After using lnTop to get some inbound capacity, Angela can send you up to 2 BTCs because you have at least 2 BTCs that are remotely balanced with lnTop, and lnTop and Angela have at least 2 BTCs remotely balanced.

Angela sends you 1 BTC and updates the balance (1BTC remaining). She can still send you a BTC.

However, in this network, Sophie can't even send you 1 BTC. If you look at the route between Sophie and you, you will find that although you have 3 BTCs as a remote balance, lnTop does not have the inbound capacity of lnFirst.

lnFirst cannot route 1 BTC payment to lnTop. So Sophie can't pay you.

For receipts, each routing node and you (receiver) need to have sufficient inbound capacity with the previous neighbor. Therefore, although you may have solved the inbound capacity of neighboring nodes, lnTop, lnTop may not have enough inbound capacity with its neighbors. Alex Bosworth, head of Lightning Lab's Lightning Infrastructure, pointed this out a few weeks ago.

Another fact makes the situation more difficult to resolve. The "revealing the local and remote balance of all nodes" cannot be done in a lightning network. As a node of the network, you can only understand the capacity of the channel without knowing its distribution between the two peers.

Who is affected by this issue?

In the Lightning Network, not all nodes are the same or have the same requirements. Looking at our example, we can identify at least three types of nodes.

Merchant node

We refer to the merchant node as the person who receives funds primarily through the Lightning Network. In the example above, you will be the merchant node, because what you are most interested in is getting paid for the stickers you sell. For it, you need to have inbound capacity. Remember: not just with your neighbors, but all the way from your customers to you.

End user node

These nodes send funds primarily through the Lightning Network. Occasionally they can also collect money from friends. Sophie and Angela will be end users. For this group of users, connecting to other nodes with well-funded merchant routes is key. They need inbound and outbound capacity, depending on their behavior.

Routing node

These nodes route payments over the network and charge a fee. LnTop and lnFirst are some examples. Their job is to detect relevant destinations, such as you, the biggest sticker merchant in town. They need the upstream inbound capacity of the end user and the outbound capacity downstream of the merchant. In addition, their fees must compete with other markets and they need to be online.

in conclusion

We have already discussed inbound capacity starting from a single payment channel, then understand the channels in the network and ultimately get complete information about other nodes.

We define inbound capacity as the amount you get through the Lightning Network at a particular time and how it depends on your remote balance.

The inbound capacity issue seems to be a guiding issue for the Lightning Network. Therefore, once there is more and better distribution of liquidity in the network, it may not be as important. We will continue to write articles about lightning networking in the early days.

Original: https://blog.muun.com/

Source (translation): https://first.vip/shareNews?id=2194&uid=1

We will continue to update Blocking; if you have any questions or suggestions, please contact us!