{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-09-24\n📝 Original message:\nOn Thu, Sep 22, 2022 at 08:40:30AM +0200, René Pickhardt via Lightning-dev wrote:\n\u003e While trying to estimate the expected liquidity distribution in depleted\n\u003e channels due to drain via Markov Models I realized that we can exploit the\n\u003e `htlc_maxium_msat` setting to act as a control valve and regulate the\n\u003e \"pressure\" coming from the drain and mitigate the depletion of channels.\n\nThis is really neat!\n\nI think \"channel drain\" confounds two issues (or, at least, I do when\nI think about it):\n\n 1) one is you're trying to collect as many forwarding fees as you can,\n    and since a drained channel prevents you from forwarding txs, that\n    feels like a hit on profits\n\n 2) the other is that a drained channel *can't* forward a payment even\n    for no profit, so even attempting to forward a payment over a drained\n    channel wastes everyone's time, increases payment latency, and may\n    increase payment failures if you go through too many failures without\n    finding a successful path\n\nThis seems like a great idea for solving (2) -- if you make lightning\nnodes look at htlc_max_msat and throttle their use of a channel based\non its value, then channels can set that value so that their payment\nflow is balanced on average, at which point depletion becomes rare,\nand payments usually succeed.\n\nI think a simple way of thinking about it is: suppose people are\nforwarding X BTC per hour through a channel in one direction, and 2X BTC\nthrough it in the other direction, with all payments being 1000 sats\nexactly. Then if you set htlc_max_msat to 500sats on the overloaded\ndirection, and everyone then triggers their AMP paths and sends half\ntheir payments through a slightly more expensive path, you'll be at\nX-vs-X BTC per hour, with balanced flows and stable channel balances.\n\nOTOH, it is relying on senders doing things that are slightly less optimal\nin the short term (pay higher fees) for things that benefit them only in\nthe long term (avoid payment latency/failures due to depleted channels),\nand only if most people cooperate. Perhaps there's some privacy-preserving\nway that channel operators could throttle payments based on htlc_max_msat\n(and channel depletion percentage?) as well, so that cheaters are less\nlikely to prosper?\n\n\n\nBut as far as (1) goes -- this isn't actually an improvement: instead\nof rejecting X BTC per hour from the overloaded direction because\nyour channel's depleted, you're now not even getting the opportunity\nto forward those payments and collect the corresponding fees. It's no\nworse for your profit margins, but it's not any better. (And it could\nbe worse if you're throttling both sides, and only getting 0.95*X BTC\nper hour in both directions.\n\nBut there aren't many ways you can actually do better with (1).\n\nOne way is if you have a cheap way to rebalance your channels -- in that\ncase, rebalance your channel, let it drain again, collecting fees all the\nwhile, and repeat. If rebalancing is cheaper than the fees you collect,\nthis works great!\n\nThe other way is if fees rates are expected to change -- if they're likely\nto go down later, then you might as well deplete your channel now, since\nyou'll collect more fees for it now than you would later; likewise if you\nexpect fees to up up later, then you might want to retain some balance\nnow, so you can deplete it later. But that's a very dynamic situation,\nand the profits are limited -- you can only drain your channel once while\nwaiting for fee rates to be ready to change, and your profit is going to\nbe capped by your channel capacity times the difference in the fee rates.\n\n\n\nThis approach seems *much* better than the fee rate cards idea:\n\n * you're not decreasing your channel profitability half the time in\n   order to avoid your channel depleting\n\n * you're making routing decisions *less* dependent on internal/private\n   state, rather than more\n\n * you're not adding much gossip/probing traffic -- you might need\n   to refine your htlc_max_msat a few times each time you change fees,\n   but it shouldn't be often, and this should be reducing the frequency\n   you have to change fees anyway\n\n * you're providing a way of throttling payment traffic independent of\n   fees -- since fees are competitive, they can have discontinuous effects\n   where a small change to fee can cause a large change to traffic volume;\n   but this seems like it should mostly have a proportional response,\n   with a small decrease in htlc_max_msat resulting in a small decrease in\n   payment volume, and conversely. Much better for stability/optimisation!\n\nCheers,\naj"}