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 >send on all your channels. 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 receive, then without active rebalancing, he's unable to receive the 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] https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announ ce_the_liquiditynetwork/ [3] https://arxiv.org/abs/1007.0515 [4] https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-netw ork-796756ad4f31 _______________________________________________ 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
