Gregorio Guidi [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-27 📝 Original message: On 5/26/22 23:32, René ...
đź“… Original date posted:2022-05-27
đź“ť Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220527/2aa3b108/attachment.html>;
đź“ť Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220527/2aa3b108/attachment.html>;