Two questions -
a) How much gossip overhead do you expect this type of protocol to generate/is there a useful
outcome for this type of update even if you limit gossip updates to once/twice/thrice per day?
b) What are the privacy implications of the naive "update on drained channel", and have you done any
analysis of the value of this type of gossip update at different levels of privacy?
Thanks,
Matt
On 9/22/22 2:40 AM, René Pickhardt via Lightning-dev wrote:
Good morning fellow Lightning Developers,
I am pleased to share my most recent research results [1] with you. They may (if at all) only have a
small impact on protocol development / specification but are actually mainly of concern to node
operators and LSPs. I still thought they may be relevant for the list.
While trying to estimate the expected liquidity distribution in depleted channels due to drain via
Markov Models I realized that we can exploit the `htlc_maxium_msat` setting to act as a control
valve and regulate the "pressure" coming from the drain and mitigate the depletion of channels. Such
ideas are btw not novel at all and heavily used in fluid networks [2]. Thus it seems very natural
that we do the same on the Lightning Network.
In the article we show within a theoretic model how expected payment failure rates per channel may
drop significantly by up to an order of magnitude if channels set up proper asymmetric
`htlc_maximum_msat` pairs.
We furthermore provide in our iPython notebook [3] two experimental algorithmic ideas with which
node operators can find decent `htlc_maximum_msat` values in a greedy fashion. One of the algorithms
does not even require to know the drain or payment size distribution or build the Markov model but
just looks at the liquidity distribution in the channel at the last x routing attempts and adjusts
the `htlc_maximum_msat` value if the distribution is to far away from a uniform distribution.
Looking forwards for your thoughts and feedback.
with kind regards Rene
[1]:
https://blog.bitmex.com/the-power-of-htlc_maximum_msat-as-a-control-valve-for-better-flow-control-improved-reliability-and-lower-expected-payment-failure-rates-on-the-lightning-network/ <https://blog.bitmex.com/the-power-of-htlc_maximum_msat-as-a-control-valve-for-better-flow-control-improved-reliability-and-lower-expected-payment-failure-rates-on-the-lightning-network/>
[2]: https://en.wikipedia.org/wiki/Control_valve
<https://en.wikipedia.org/wiki/Control_valve>
[3]:
https://github.com/lnresearch/Flow-Control-on-Lightning-Network-Channels-with-Drain-via-Control-Valves/blob/main/htlc_maximum_msat%20as%20a%20valve%20for%20flow%20control%20on%20the%20Lightnig%20network.ipynb <https://github.com/lnresearch/Flow-Control-on-Lightning-Network-Channels-with-Drain-via-Control-Valves/blob/main/htlc_maximum_msat%20as%20a%20valve%20for%20flow%20control%20on%20the%20Lightnig%20network.ipynb>
--
https://ln.rene-pickhardt.de <https://ln.rene-pickhardt.de>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
