From greg_g at posteo.net Fri May 27 16:28:40 2022 From: greg_g at posteo.net (Gregorio Guidi) Date: Fri, 27 May 2022 16:28:40 +0000 Subject: [Lightning-dev] Principle Limitations to the reliability of the Lightning Network Protocol In-Reply-To: References: Message-ID: On 5/26/22 23:32, Ren? Pickhardt via Lightning-dev wrote: > Dear fellow lightning developers, > > please note my recent blog article titled "Price of Anarchy from > selfish routing strategies on the Lightning Network" [1] where we > investigate how the selfish behavior of nodes sending Bitcoin over the > Lightning Network may lead to higher drain on channels which in turn > is expected to result in higher depletion and failure rates for > payments on the network. All of the observations have been derived > purely be looking at statistical measures and computations on the data > that the Gossip Protocol and Bitcoin Network provides about the > topology of the Lightning Network. No probing or empirical experiments > had to be conducted to derive these theoretical results. All code can > be found in the lnresearch repository at [2]. > > ... > > I hope the described effects won't be too strong for the expected > traffic and usage of the network so that the technology will work > properly at the required scale. I am very happy for your thoughts, > feedback, comments and questions as I find it fascinating to see how > the game theory of the Lightning network will eventually play out and > at least in my current understanding seems to produce limitations to > the amount of traffic the protocol may eventually be able to handle. > > with kind Regards Rene Pickhardt > > [1]: > https://blog.bitmex.com/price-of-anarchy-from-selfish-routing-strategies/ > [2]: https://github.com/lnresearch/Price-Of-Anarchy-in-Selfish-Routing Dear Ren?, a few years ago I made a very small contribution to this list by posting a paper on "Modeling a Steady-State Lightning Network Economy": https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002115.html I mention it here because perhaps there are some ideas tangentially related to the research program you are conducting on routing strategies. I copy below the abstract and a relevant quote (full paper here: https://github.com/gr-g/ln-steady-state-model). In particular you can find a link between the idea of "drain" you defined and the concept of "demand imbalance" in the paper. Abstract: /In this paper, we consider an idealized scenario in which the Lightning // //Network (or any similar payment network) has scaled to the size and // //volume of a self-sustained economy, meaning that the number of on-chain // //transactions - including channel opening and closing - has become // //negligible when compared to the number of off-chain transactions, and // //payments continuously flow across a network with relatively stable // //topology. We take this scenario to the extreme and model a network where // //the channels are fixed, so that payments form a completely closed // //system, and where nodes have (on a long enough timescale) stable and // //perfectly balanced incoming and outgoing payments (i.e. they spend // //exactly what they earn). We call this scenario the "steady-state // //economy" of the payment network.// // //We argue that in such scenario, in a network of n connected nodes, // //there is a tendency towards a state where exactly n-1 channels have // //perfectly balanced flows in the two directions ("self-balancing" // //channels), while all other channels are either unused, or have a // //permanent tendency towards imbalance: the channel balance accumulates at // //one end and the channel is only intermittently available in one // //direction ("stuttering" channels). We note that the "self-balancing" // //channels form a spanning tree of the network graph, which we call the // //"core spanning tree" of the payment network.// // //We also try to derive some practical lessons from this idealized // //scenario, hopefully providing some useful insight to node operators of // //the current (embryonic) Lightning Network.// // //At the end of the paper, we provide some remarks on the more general // //case in which nodes do not balance their income and expenses.// / From section 4: /There is general consensus on the //fact that having a large fraction of channels not usable or barely usable in one////direction is not a healthy predicament for the network, and that some form of////channel management will need to be practiced by node operators involving a mix////of rebalancing and fee fine-tuning. However, one of the main takeaways of the////analysis of the steady-state model is that the network might have a tendency////to push////most////of the channels (when not unused) towards being chronically////unbalanced.// //We wonder if these two tools (rebalancing and fee management) are really// //enough to contrast the tendency toward imbalance. If not, it would be appro-// //priate to consider also other strategies to ?work with the imbalances? instead// //of fighting them.////We refer, for example, to efficient low-latency mechanisms// //to signal when a channel becomes unusable in one direction, in order to limit// //the failure rate, together with a general robustness of the network against a// //pervasive and high-volume flow of information about channels that switch from// //being available to not available and vice versa (or that switch between low fees// //and high fees)./ Kind regards, Gregorio -------------- next part -------------- An HTML attachment was scrubbed... URL: