From ZmnSCPxj at protonmail.com Wed Jul 11 07:56:20 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Wed, 11 Jul 2018 03:56:20 -0400 Subject: [Lightning-dev] Rebalancing argument In-Reply-To: References: Message-ID: 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 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 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 >>>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 >> Date: Tuesday, 3 July 2018 at 22:13 >> To: Dmytro Piatkivskyi >> Cc: "lightning-dev at 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 >> >> >> -- Laolu >> >> On Sun, Jul 1, 2018 at 5:21 AM Dmytro Piatkivskyi >> 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 >> > 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 at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: