📅 Original date posted:2018-07-03
📝 Original message:
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 <
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/001005.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/001005.html
> [2]
> https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announce_the_liquiditynetwork/
> [3] https://arxiv.org/abs/1007.0515
> [4]
> https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-network-796756ad4f31
> _______________________________________________
> 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/20180703/29d80ad3/attachment-0001.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:51:00
in reply to nevent1q…sjh5
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:51:00Event JSON
{
"id": "a0885a5dc8a095a275ec5c2c2bbafde553ed22629fa95acf582dbe3cac37a33d",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315060,
"kind": 1,
"tags": [
[
"e",
"2d2d70fc0be627afa7248f58845394ba9de062cbe9d0a9ff8d13fc15b7b40c02",
"",
"root"
],
[
"e",
"f6c01d5da1ea3050f6187176dc57f0c9ec1f4c7cd8700ddf8f3983d3aaea1deb",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2018-07-03\n📝 Original message:\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 question.\nWe\nwe're discussing if \"active rebalancing\" was actually ever really necessary.\n\u003eFrom my PoV, active rebalancing is rebalancing done for the purpose of being\nable to send/recv a particular payment. On white board, cdecer sketched out\na\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 BTC\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 (or\nthe\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 result,\nactive rebalancing isn't needed as payments can be split up to fully utilize\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\nparticular\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 or\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 and\nis\na problem that's been explored in the existing literature.\n\n[1]: https://blog.lightning.engineering/posts/2018/05/30/routing.html\n\n-- Laolu\n\n\nOn Sun, Jul 1, 2018 at 5:21 AM Dmytro Piatkivskyi \u003c\ndmytro.piatkivskyi at ntnu.no\u003e wrote:\n\n\u003e Hi everyone,\n\u003e\n\u003e I have been working academically on the Lightning network for a while now.\n\u003e I didn’t not participate in the list to form my own vision of what it\n\u003e should be. So please, bear with me if I’ll be saying nonsense sometimes.\n\u003e\n\u003e There has been a lot of discussion on sending cycle transactions to\n\u003e oneself to ‘re-balance’ the network. On LN mailing list\n\u003e \u003chttps://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html\u003e [1] or\n\u003e numerous places elsewhere. There has been even a paper suggesting a smart\n\u003e mechanism to do the re-balancing (see Revive or Liquidity network [2]). My\n\u003e question is what do we actually get from it? [3] states that the\n\u003e distribution of funds in channels does not really affect the network\n\u003e liquidity. I can see cheaper fees or shorter paths if the network is kept\n\u003e balanced. But don’t you think that a smart fee strategy will do the job?\n\u003e\n\u003e To save your time, [4] explains the gist from [3].\n\u003e\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html\n\u003e [2]\n\u003e https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announce_the_liquiditynetwork/\n\u003e [3] https://arxiv.org/abs/1007.0515\n\u003e [4]\n\u003e https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-network-796756ad4f31\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180703/29d80ad3/attachment-0001.html\u003e",
"sig": "1635a74f56436fa6354ed608413cea5be49679a6131c6f6e3007fd52b622f85a97dc0947c931ce65de40eee09d9cb0e1262d6796e79ec7739020f2a10e206947"
}