📅 Original date posted:2018-07-10
📝 Original message:
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.piatkivskyi at 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
>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 <laolu32 at gmail.com>
Date: Tuesday, 3 July 2018 at 22:13
To: Dmytro Piatkivskyi <dmytro.piatkivskyi at ntnu.no>
Cc: "lightning-dev at lists.linuxfoundation.org"
<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
<https://blog.lightning.engineering/posts/2018/05/30/routing.html>;
-- Laolu
On Sun, Jul 1, 2018 at 5:21 AM Dmytro Piatkivskyi
<dmytro.piatkivskyi at 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 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180710/aa9097bd/attachment.html>;
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:51:01
in reply to nevent1q…gyfg
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:51:01Event JSON
{
"id": "b7a2a5184d458b4b7b207c6ae8effdbebda57f9469af901b393c721c72fd172f",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686315061,
"kind": 1,
"tags": [
[
"e",
"2d2d70fc0be627afa7248f58845394ba9de062cbe9d0a9ff8d13fc15b7b40c02",
"",
"root"
],
[
"e",
"338e9a2888a955c2f0b6adfabe0cbde604aa0002ceda23e9b0bd5898cc4a7ea2",
"",
"reply"
],
[
"p",
"860a8852674ea84487c624b0e6d6c006fc0d7f67600add2602672c70fc97a177"
]
],
"content": "📅 Original date posted:2018-07-10\n📝 Original message:\nA 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.\nIf 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).\n\nOn Thu, Jul 5, 2018 at 12:06, Dmytro Piatkivskyi \u003cdmytro.piatkivskyi at ntnu.no\u003e wrote:\nHi Olaoluwa,\n\nI¹m glad we¹re thinking the same direction.\n\nGenerally, I think we (the community) worry too much about equilibrium.\nThere is no really proof that it improves the network. On the other hand,\nmoney being locked in channel is of major issue. Some nodes may be used\nmostly for sending payments, whereas others mostly receiving. Therefore,\nthe distribution of funds in channels should be dictated not by\nequilibrium but by nodes' plans to send and receive.\n\n\u003e In this case, equilibrium means being able to recv as much as you can\n\u003esend on all your channels.\n\nNow it seems there are two ways to define equilibrium. You have described\none where each node is trying to keep the ability to send and receive at\nthe same level. I¹ll repeat the above argument, some nodes may be used\nmostly for sending payments, whereas others mostly receiving. Therefore,\nsuch definition is unjustified from the individual viewpoint. Another\ndefinition of equilibrium is when a node distributes equally the available\nbalance amongst the channels it has. Your argument still stands here as\nsuch equilibrium minimises the number of depleted channels.\n\n\u003e The argument here is that by maintaining this balance, one is likely to\n\u003ereduce the number of routing failures from failed HTLC forwarding, as the\n\u003echannel is equally likely to be able to carry an HTLC in either direction.\n\nIf a node has no balance, its channels are depleted. There is nothing we\ncan do with this. Such nodes are bad for topology and should be\ndiscouraged. Possibly by the autopilot.\n\n\u003e However if a few sources/sinks dominate, then channels may regularly\n\u003ebecome biased requiring more maintenance.\n\nNow you¹re bringing up even more important question. If we had balanced\npayments, LN could function without touching blockchain ever again\nindefinitely. Skewed traffic is a big problem. Re-balancing won¹t be of\nuse here because having a fixed nodes¹ balances, there is only a limited\nmax flow that can be pushed in a particular direction. I believe autopilot\ncould mitigate the problem. Please, find my argument at the bottom of [1].\n\n[1] https://github.com/lightningnetwork/lnd/issues/677\n\n\nBest,\nDmytro\n\nFrom: Olaoluwa Osuntokun \u003claolu32 at gmail.com\u003e\nDate: Tuesday, 3 July 2018 at 22:13\nTo: Dmytro Piatkivskyi \u003cdmytro.piatkivskyi at ntnu.no\u003e\nCc: \"lightning-dev at lists.linuxfoundation.org\"\n\u003clightning-dev at lists.linuxfoundation.org\u003e\nSubject: Re: [Lightning-dev] Rebalancing argument\n\n\nHi Dmytro,\n\nThanks for bringing this up! Sometime last year when I was at a developer\nmeetup that cdecker also attended, we briefly discussed a similar\nquestion. We\nwe're discussing if \"active rebalancing\" was actually ever really\nnecessary.\n\u003eFrom my PoV, active rebalancing is rebalancing done for the purpose of\nbeing\nable to send/recv a particular payment. On white board, cdecer sketched\nout a\nsimilar argument as to Lemma 2 in that paper you linked: namely that there\nwill\nexist an alternative path, therefore active rebalancing isn't necessary.\n\nIMO, in a world pre-AMP, it is indeed necessary. Consider a node Bob that\nwishes to receive a payment of 0.5 BTC. Bob has two channels, one with 2\nBTC\nmax capacity, and the other with 1 BTC max capacity. If channel 1 only has\n0.2\navailable for him to receive, and channel 2 only has 0.3 available for him\nto\nreceive, then without active rebalancing, he's unable to receive the\npayment.\nHowever, if he completes a circular payment from channel 1 to channel 2\n(or the\nother way around), then he's able to receive the payment (under ideal\nconditions).\n\nIn a world post-AMP, then this would seem to no longer apply. Alice the\nsender\nmay be able to utilize the aggregate bandwidth of the network to send\nminimally\ntwo payment flows (one 0.2 and one 0.3) to satisfy the payment. As a\nresult,\nactive rebalancing isn't needed as payments can be split up to fully\nutilize\nthe payment bandwidth at both the sender and the receiver.\n\n\u003e total balances of nodes in the network define the feasibility of a\n\u003eparticular\n\u003e transaction, not the distribution of balances.\n\nWith multi-path payments this is precisely the case!\n\nHowever, there might be an argument in favor of \"passive rebalancing\". I\ndefine\npassive rebalancing as rebalancing a node carries out independent of\nneeding to\nsend/receive payments themselves, in order to ensure an equilibrium state\namongst the available balances of their channels. In this case, equilibrium\nmeans being able to recv as much as you can send on all your channels. The\nargument here is that by maintaining this balance, one is likely to reduce\nthe\nnumber of routing failures from failed HTLC forwarding, as the channel is\nequally likely to be able to carry an HTLC in either direction.\n\nOne relevant detail w.r.t to the necessity of active rebalancing is the\ndirectionality of payment flows in the network. If payment flows are more\nor\nless balanced (kinda like the ideal world Byran Vu describes in the post\n[1]),\nmeaning people are sending out as much as they receive (so they get their\npaycheck streamed to them over LN, then stream BitFlix w/ that), then it's\npossible passive rebalancing isn't really necessary. However if a few\nsources/sinks dominate, then channels may regularly become biased requiring\nmore maintenance.\n\nAlso thanks for bringing this paper to my attention! Haven't yet read it in\nfull yet, but happy to discover that this isn't completes new territory\nand is\na problem that's been explored in the existing literature.\n\n[1]:\nhttps://blog.lightning.engineering/posts/2018/05/30/routing.html\n\u003chttps://blog.lightning.engineering/posts/2018/05/30/routing.html\u003e\n\n-- Laolu\n\n\nOn Sun, Jul 1, 2018 at 5:21 AM Dmytro Piatkivskyi\n\u003cdmytro.piatkivskyi at ntnu.no\u003e wrote:\n\n\nHi everyone,\n\nI have been working academically on the Lightning network for a while now.\nI didn¹t not participate in the list to form my own vision of what it\nshould be. So please, bear with me if I¹ll be saying nonsense sometimes.\n\nThere has been a lot of discussion on sending cycle transactions to\noneself to Œre-balance¹ the network. On LN mailing list\n\u003chttps://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/00\n1005.html\u003e [1] or numerous\nplaces elsewhere. There has been even a paper suggesting a smart\nmechanism to do the re-balancing (see Revive or Liquidity network [2]). My\nquestion is what do we actually get from it? [3] states that the\ndistribution of funds in channels does not really affect\nthe network liquidity. I can see cheaper fees or shorter paths if the\nnetwork is kept balanced. But don¹t you think that a smart fee strategy\nwill do the job?\n\nTo save your time, [4] explains the gist from [3].\n\n[1]\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001\n005.html\n[2]\nhttps://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announ\nce_the_liquiditynetwork/\n[3] https://arxiv.org/abs/1007.0515\n[4]\nhttps://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-netw\nork-796756ad4f31\n\n\n_______________________________________________\nLightning-dev mailing list\nLightning-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\n_______________________________________________\nLightning-dev mailing list\nLightning-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180710/aa9097bd/attachment.html\u003e",
"sig": "db4ab3a29d3973520c4846c7aa34436f5f9c0e5ace1791e9d166370b3bc8ee2ef46627255873215bc0ecd3dc10b2c494da0b5783194402b00004ccd4ffeae5a9"
}