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.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/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@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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
