# Re: [Lightning-dev] Rebalancing argument

```Good morning,

I believe care must be taken for automatic rebalancing.```
```
Suppose we start in this state:

A
1.0|\1.0
| \
1.0|  \1.0
B---C
1.0 1.0

Then A pays to B 1.0 BTC:

A
0.0|\1.0
| \
2.0|  \1.0
B---C
1.0 1.0

In an effort to balance, B moves 0.5 from A-B to B-C:

A
0.5|\0.5
| \
1.5|  \1.5
B---C
1.5 0.5

In an effort to balance, C moves 0.5 from A-C to C-B:

A
0.0|\1.0
| \
2.0|  \1.0
B---C
1.0 1.0

Which again triggers B to balance, setting both of them up to fight each other
while A just charges them fees on the payments both ways.

Eventually it settles with A recouping the entire 1.0 it paid to B from the
fees of both B and C fighting things out between them about keeping their
channels balanced.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 10, 2018 6:23 PM, Johan Torås Halseth <joha...@gmail.com> wrote:

> A simple way to see how rebalancing could be beneficial, is to observe that
> you only know the channel capacity (not the balance!) of the channels you
> don’t belong to.
>
> If everybody is being good stewards and are rebalancing their channels, then
> picking a route to send a payment over is more likely to succeed than if
> everybody only has channels depleted in one direction (extreme case).
>
> On Thu, Jul 5, 2018 at 12:06, Dmytro Piatkivskyi <dmytro.piatkivs...@ntnu.no>
> wrote:
>
>> Hi Olaoluwa,
>>
>> I¹m glad we¹re thinking the same direction.
>>
>> Generally, I think we (the community) worry too much about equilibrium.
>> There is no really proof that it improves the network. On the other hand,
>> money being locked in channel is of major issue. Some nodes may be used
>> mostly for sending payments, whereas others mostly receiving. Therefore,
>> the distribution of funds in channels should be dictated not by
>> equilibrium but by nodes' plans to send and receive.
>>
>>> In this case, equilibrium means being able to recv as much as you can
>>
>> Now it seems there are two ways to define equilibrium. You have described
>> one where each node is trying to keep the ability to send and receive at
>> the same level. I¹ll repeat the above argument, some nodes may be used
>> mostly for sending payments, whereas others mostly receiving. Therefore,
>> such definition is unjustified from the individual viewpoint. Another
>> definition of equilibrium is when a node distributes equally the available
>> balance amongst the channels it has. Your argument still stands here as
>> such equilibrium minimises the number of depleted channels.
>>
>>> The argument here is that by maintaining this balance, one is likely to
>>>reduce the number of routing failures from failed HTLC forwarding, as the
>>>channel is equally likely to be able to carry an HTLC in either direction.
>>
>> If a node has no balance, its channels are depleted. There is nothing we
>> can do with this. Such nodes are bad for topology and should be
>> discouraged. Possibly by the autopilot.
>>
>>> However if a few sources/sinks dominate, then channels may regularly
>>>become biased requiring more maintenance.
>>
>> Now you¹re bringing up even more important question. If we had balanced
>> payments, LN could function without touching blockchain ever again
>> indefinitely. Skewed traffic is a big problem. Re-balancing won¹t be of
>> use here because having a fixed nodes¹ balances, there is only a limited
>> max flow that can be pushed in a particular direction. I believe autopilot
>> could mitigate the problem. Please, find my argument at the bottom of [1].
>>
>> [1] https://github.com/lightningnetwork/lnd/issues/677
>>
>> Best,
>> Dmytro
>>
>> From: Olaoluwa Osuntokun <laol...@gmail.com>
>> Date: Tuesday, 3 July 2018 at 22:13
>> To: Dmytro Piatkivskyi <dmytro.piatkivs...@ntnu.no>
>> Cc: "lightning-dev@lists.linuxfoundation.org"
>> <lightning-dev@lists.linuxfoundation.org>
>> Subject: Re: [Lightning-dev] Rebalancing argument
>>
>> Hi Dmytro,
>>
>> Thanks for bringing this up! Sometime last year when I was at a developer
>> meetup that cdecker also attended, we briefly discussed a similar
>> question. We
>> we're discussing if "active rebalancing" was actually ever really
>> necessary.
>> From my PoV, active rebalancing is rebalancing done for the purpose of
>> being
>> able to send/recv a particular payment. On white board, cdecer sketched
>> out a
>> similar argument as to Lemma 2 in that paper you linked: namely that there
>> will
>> exist an alternative path, therefore active rebalancing isn't necessary.
>>
>> IMO, in a world pre-AMP, it is indeed necessary. Consider a node Bob that
>> wishes to receive a payment of 0.5 BTC. Bob has two channels, one with 2
>> BTC
>> max capacity, and the other with 1 BTC max capacity. If channel 1 only has
>> 0.2
>> available for him to receive, and channel 2 only has 0.3 available for him
>> to
>> payment.
>> However, if he completes a circular payment from channel 1 to channel 2
>> (or the
>> other way around), then he's able to receive the payment (under ideal
>> conditions).
>>
>> In a world post-AMP, then this would seem to no longer apply. Alice the
>> sender
>> may be able to utilize the aggregate bandwidth of the network to send
>> minimally
>> two payment flows (one 0.2 and one 0.3) to satisfy the payment. As a
>> result,
>> active rebalancing isn't needed as payments can be split up to fully
>> utilize
>> the payment bandwidth at both the sender and the receiver.
>>
>>> total balances of nodes in the network define the feasibility of a
>>>particular
>>> transaction, not the distribution of balances.
>>
>> With multi-path payments this is precisely the case!
>>
>> However, there might be an argument in favor of "passive rebalancing". I
>> define
>> passive rebalancing as rebalancing a node carries out independent of
>> needing to
>> send/receive payments themselves, in order to ensure an equilibrium state
>> amongst the available balances of their channels. In this case, equilibrium
>> means being able to recv as much as you can send on all your channels. The
>> argument here is that by maintaining this balance, one is likely to reduce
>> the
>> number of routing failures from failed HTLC forwarding, as the channel is
>> equally likely to be able to carry an HTLC in either direction.
>>
>> One relevant detail w.r.t to the necessity of active rebalancing is the
>> directionality of payment flows in the network. If payment flows are more
>> or
>> less balanced (kinda like the ideal world Byran Vu describes in the post
>> [1]),
>> meaning people are sending out as much as they receive (so they get their
>> paycheck streamed to them over LN, then stream BitFlix w/ that), then it's
>> possible passive rebalancing isn't really necessary. However if a few
>> sources/sinks dominate, then channels may regularly become biased requiring
>> more maintenance.
>>
>> Also thanks for bringing this paper to my attention! Haven't yet read it in
>> full yet, but happy to discover that this isn't completes new territory
>> and is
>> a problem that's been explored in the existing literature.
>>
>> [1]:
>> https://blog.lightning.engineering/posts/2018/05/30/routing.html
>> <https://blog.lightning.engineering/posts/2018/05/30/routing.html>
>>
>> -- Laolu
>>
>> On Sun, Jul 1, 2018 at 5:21 AM Dmytro Piatkivskyi
>> <dmytro.piatkivs...@ntnu.no> wrote:
>>
>> Hi everyone,
>>
>> I have been working academically on the Lightning network for a while now.
>> I didn¹t not participate in the list to form my own vision of what it
>> should be. So please, bear with me if I¹ll be saying nonsense sometimes.
>>
>> There has been a lot of discussion on sending cycle transactions to
>> oneself to Œre-balance¹ the network. On LN mailing list
>> <https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/00
>> 1005.html> [1] or numerous
>> places elsewhere. There has been even a paper suggesting a smart
>> mechanism to do the re-balancing (see Revive or Liquidity network [2]). My
>> question is what do we actually get from it? [3] states that the
>> distribution of funds in channels does not really affect
>> the network liquidity. I can see cheaper fees or shorter paths if the
>> network is kept balanced. But don¹t you think that a smart fee strategy
>> will do the job?
>>
>> To save your time, [4] explains the gist from [3].
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001
>> 005.html
>> [2]
>> ce_the_liquiditynetwork/
>> [3] https://arxiv.org/abs/1007.0515
>> [4]
>> https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-netw
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev```
```_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
```