Hi Rene, Thanks for your answer!
1. The Lightning network operates under different assumptions, that is true. However, the difference is minor in terms of the issue posed. The premise for the quoted statement is that taking fees changes the nodes’ balances, therefore selected paths affect the liquidity. In the Lightning network fees are very small, so the change in liquidity may be negligible. Moreover, intermediate nodes gain in fees, which only increases the liquidity. 2.A. It is too early to speculate where the privacy requirements will settle down. Flare suggests a mechanism of sharing the infrastructure view between nodes, possibly sharing weights. As the network grows routing will become more difficult, however we don’t know yet to which extent. It may organise itself in ‘domains’, so when we send a payment we know to which domain we are sending to, knowing the path to it beforehand. The point is we don’t know yet, so we can’t speculate. 2.B. That is surely an interesting aspect. HTLC locks temporarily downgrade the network liquidity. Now the question is how it changes the order of transactions and how that order change affects the transaction feasibility. Does it render some transactions infeasible or just defers them? It definitely needs a closer look. Yet the question remains — are there obvious advantages of cycle transactions over a smart fee/routing system? In any sense. Path lengths, for example. To answer that I am going to run a simulation, but also would appreciate your opinions. Best, Dmytro From: René Pickhardt <r.pickha...@googlemail.com<mailto:r.pickha...@googlemail.com>> Date: Sunday, 1 July 2018 at 13:59 To: Dmytro Piatkivskyi <dmytro.piatkivs...@ntnu.no<mailto:dmytro.piatkivs...@ntnu.no>> Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org<mailto:lightning-dev@lists.linuxfoundation.org>> Subject: Re: [Lightning-dev] Rebalancing argument 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<mailto: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<mailto:Lightning-dev@lists.linuxfoundation.org> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -- www.rene-pickhardt.de<http://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
