{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-09-23\n📝 Original message:\nTwo questions -\na) How much gossip overhead do you expect this type of protocol to generate/is there a useful \noutcome for this type of update even if you limit gossip updates to once/twice/thrice per day?\nb) What are the privacy implications of the naive \"update on drained channel\", and have you done any \nanalysis of the value of this type of gossip update at different levels of privacy?\n\nThanks,\nMatt\n\nOn 9/22/22 2:40 AM, René Pickhardt via Lightning-dev wrote:\n\u003e Good morning fellow Lightning Developers,\n\u003e \n\u003e I am pleased to share my most recent research results [1] with you. They may (if at all) only have a \n\u003e small impact on protocol development / specification but are actually mainly of concern to node \n\u003e operators and LSPs. I still thought they may be relevant for the list.\n\u003e \n\u003e While trying to estimate the expected liquidity distribution in depleted channels due to drain via \n\u003e Markov Models I realized that we can exploit the `htlc_maxium_msat` setting to act as a control \n\u003e valve and regulate the \"pressure\" coming from the drain and mitigate the depletion of channels. Such \n\u003e ideas are btw not novel at all and heavily used in fluid networks [2]. Thus it seems very natural \n\u003e that we do the same on the Lightning Network.\n\u003e \n\u003e In the article we show within a theoretic model how expected payment failure rates per channel may \n\u003e drop significantly by up to an order of magnitude if channels set up proper asymmetric \n\u003e `htlc_maximum_msat` pairs.\n\u003e \n\u003e We furthermore provide in our iPython notebook [3] two experimental algorithmic ideas with which \n\u003e node operators can find decent `htlc_maximum_msat` values in a greedy fashion. One of the algorithms \n\u003e does not even require to know the drain or payment size distribution or build the Markov model but \n\u003e just looks at the liquidity distribution in the channel at the last x routing attempts and adjusts \n\u003e the `htlc_maximum_msat` value if the distribution is to far away from a uniform distribution.\n\u003e \n\u003e Looking forwards for your thoughts and feedback.\n\u003e \n\u003e with kind regards Rene\n\u003e \n\u003e \n\u003e [1]: \n\u003e 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/ \u003chttps://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/\u003e\n\u003e [2]: https://en.wikipedia.org/wiki/Control_valve \u003chttps://en.wikipedia.org/wiki/Control_valve\u003e\n\u003e [3]: \n\u003e 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 \u003chttps://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\u003e\n\u003e \n\u003e -- \n\u003e https://ln.rene-pickhardt.de \u003chttps://ln.rene-pickhardt.de\u003e\n\u003e \n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}