RenĆ© Pickhardt [ARCHIVE] on Nostr: š Original date posted:2018-07-01 š Original message: Hey Dmytro, thank your ...
š
Original date posted:2018-07-01
š Original message:
Hey Dmytro,
thank your for your solid input to the discussion. I think we need to
consider that the setting in the lightning network is not exactly
comparable to the one described in the 2010 paper.
1st: the paper states in section 5.2: "It appears that a mathematical
analysis of a transaction routing model where intermediate nodes charged a
routing fee would require an entirely new approach since it would
invalidate the cycle-reachability relation that forms the basis of our
results."
Since we have routing fees in the lightning network to my understanding the
theorem and lemma you quoted in your medium post won't hold.
2nd: Even if we neglect the routing fees and assume the theorem still holds
true we have two conditions that make the problem way more dynamic:
A) In the lightning network we do not know the weights of the directed
edges. (only the sum of two opposing edges) So while theoretically the flow
in the network will only depend on the liquidity of the nodes I guess in
practice well balanced channels will increase the probability to actually
find a working route.
B) I believe the HTLCs create a situation where funds are being locked up
while routing takes place and thus have an impact to the entire flow of the
network. While Alice searches for a route for her payment a proper route
could be blocked do to the fact that Bob is using it currently. Since the
funds of Bob have not arrived Alice might also not be able to find a
different route.
However those scientific results are a strong call for Atomic Multipath
Payments. I personally think they are also a strong call for splicing since
this allows to easilly increase the flow of the network by updating a
channel (athough you might argue that following the paper this could be
achieved by just creating a new channel)
best Rene
On Sun, Jul 1, 2018 at 12:21 PM 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
>
--
www.rene-pickhardt.de
<http://www.beijing-china-blog.com/>;
Skype: rene.pickhardt
mobile: +49 (0)176 5762 3618
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180701/288b5422/attachment.html>;
š Original message:
Hey Dmytro,
thank your for your solid input to the discussion. I think we need to
consider that the setting in the lightning network is not exactly
comparable to the one described in the 2010 paper.
1st: the paper states in section 5.2: "It appears that a mathematical
analysis of a transaction routing model where intermediate nodes charged a
routing fee would require an entirely new approach since it would
invalidate the cycle-reachability relation that forms the basis of our
results."
Since we have routing fees in the lightning network to my understanding the
theorem and lemma you quoted in your medium post won't hold.
2nd: Even if we neglect the routing fees and assume the theorem still holds
true we have two conditions that make the problem way more dynamic:
A) In the lightning network we do not know the weights of the directed
edges. (only the sum of two opposing edges) So while theoretically the flow
in the network will only depend on the liquidity of the nodes I guess in
practice well balanced channels will increase the probability to actually
find a working route.
B) I believe the HTLCs create a situation where funds are being locked up
while routing takes place and thus have an impact to the entire flow of the
network. While Alice searches for a route for her payment a proper route
could be blocked do to the fact that Bob is using it currently. Since the
funds of Bob have not arrived Alice might also not be able to find a
different route.
However those scientific results are a strong call for Atomic Multipath
Payments. I personally think they are also a strong call for splicing since
this allows to easilly increase the flow of the network by updating a
channel (athough you might argue that following the paper this could be
achieved by just creating a new channel)
best Rene
On Sun, Jul 1, 2018 at 12:21 PM 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
>
--
www.rene-pickhardt.de
<http://www.beijing-china-blog.com/>;
Skype: rene.pickhardt
mobile: +49 (0)176 5762 3618
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180701/288b5422/attachment.html>;