Tag: payment

Closing channels alone is not an appropriate redistribution solution because it merely converts the problem.

Consider the following scenario: You have a node ONThis is a shop and a personal node Bwhich is private. They have private channels I and j between the two nodes. There are some channels that you have open on your shop front. 1, 2, and 3each of which has channels open with x, y, z respectively. Your personal node also has open channels w and v,

I will use = to specify the outgoing capacity of your merchant node, and - to display the incoming capacity.

(x) ---- | ==== (1) ---- | ==== ==== | ---- ==== | ---- (w)
 / I  /
(y) ---- | ==== (2) ---- | ==== (A) (B) ==== | ---- (v)
/  j /
(z) ---- | ==== (3) ---- | ==== ==== | ----

Suppose all channels have a capacity of 8ksat and are all evenly balanced. Let's see what happens when z makes 4ksat.

(x) ---- | ==== (1) ---- | ==== ==== | ---- ==== | ---- (w)
 / I  /
(y) ---- | ==== (2) ---- | ==== (A) (B) ==== | ---- (v)
/  j /
(z) | ======== (3) | ======== ==== | ----                     

The incoming capacities of the channels in between z, 3 and your dealer's node ON are now exhausted and you can not receive any payments. To make up for this, you must make a payment 3 and zto be received over w or v, Suppose we divide this into two payments over both w and v,

2ksat: A -> 3 -> z -> ... -> w -> B (i) -> A
2ksat: A -> 3 -> z -> ... -> v -> B (i) -> A

(x) ---- | ==== (1) ---- | ==== ======== | ====== | - (w)
 / I  /
(y) ---- | ==== (2) ---- | ==== (A) (B) ====== | - (v)
/  j /
(z) ---- | ==== (3) ---- | ==== ==== | ----                     

channel I is now exhausted, so we can close it to pay off the chain. But we need something to replace it. We need a new channel kwith the same capacity of 8ksat.

(x) ---- | ==== (1) ---- | ==== | -------- ====== | - (w)
 / k  /
(y) ---- | ==== (2) ---- | ==== (A) (B) ====== | - (v)
/  j /
(z) ---- | ==== (3) ---- | ==== ==== | ----                             

Note that We did not win anything on-chainbecause we had to reuse those funds to build the replacement channel, even though we still own the money, it's tied up in the channel.

Take this now x pays a 4ksat payment, and we repeat the above process, but use j instead of I as a channel with which we can withdraw money.

(x) | ======== (1) | ======== | -------- ====== | - (w)
 / k  /
(y) ---- | ==== (2) ---- | ==== (A) (B) ====== | - (v)
/  j /
(z) ---- | ==== (3) ---- | ==== ==== | ----

2ksat: A -> 1 -> x -> ... -> w -> B (j) -> A
2ksat: A -> 1 -> x -> ... -> v -> B (j) -> A

(x) ---- | ==== (1) ---- | ==== | -------- ======== | (W)
 / k  /
(y) ---- | ==== (2) ---- | ==== (A) (B) ======== | (V)
/  j /
(z) ---- | ==== (3) ---- | ==== ======== |                     

We can withdraw j and create l In its place, but we have the problem that the channels B had with w and v are now completely exhausted from the incoming capacity. We can not compensate for anything else, though y makes the same payment.

(x) ---- | ==== (1) ---- | ==== | -------- ======== | (W)
 / k  /
(y) | ======== (2) | ======== (A) (B) ======== | (V)
/  l /
(z) ---- | ==== (3) ---- | ==== | --------                    

So unless B is active in the lightning network, by w and vThese channels will not be reusable for realignment. It is not possible to spend B back to ON through these channels, as this would deplete the input capacities of its other channels, which are open to customers.

In practice, you probably have more channels open, and each node forwards payments to other people, possibly changing their direction. You may find that certain paths are used more frequently in one direction than another, making them ideal for use as a balancing path.

However, the ultimate goal is ultimately that you do not have to make any payments, but do your shopping directly on the network. Likewise, you should be able to get paid over the network, and redistributing less of a problem as you increase the number of channels and increase your liquidity.

There are a number of services that can be used in return for direct payments in the chain to "populate" channels. I think there is also a market for the opposite of such a service – to exchange the payment channels for the on-chain payment. Some suggestions have been made for liquidity markets that should be developed directly on the Lightning network layer so that some of them can be automated in the future.

Maybe it's the right thing to do if you're not trying to restore balance unless it's absolutely necessary for you. When in the above scenario z paid first instead of trying to rebalance the channel ON has open with 3You could just close this channel and withdraw. If z would like to make another payment to you, they either have to do it 1 or 2or another channel that may be created with incoming capacity in your direction. The problem is not with you, but z& # 39; see Fig. If you're a useful routing node, people probably want to open more inbound channels for you.

1, 2, and 3 are not necessarily your customers. Your customers are x, y and zand the direct channels you have available make these payments easy.