On Thu, Sep 22, 2022 at 08:40:30AM +0200, René Pickhardt via Lightning-dev wrote: > 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.
This is really neat! I think "channel drain" confounds two issues (or, at least, I do when I think about it): 1) one is you're trying to collect as many forwarding fees as you can, and since a drained channel prevents you from forwarding txs, that feels like a hit on profits 2) the other is that a drained channel *can't* forward a payment even for no profit, so even attempting to forward a payment over a drained channel wastes everyone's time, increases payment latency, and may increase payment failures if you go through too many failures without finding a successful path This seems like a great idea for solving (2) -- if you make lightning nodes look at htlc_max_msat and throttle their use of a channel based on its value, then channels can set that value so that their payment flow is balanced on average, at which point depletion becomes rare, and payments usually succeed. I think a simple way of thinking about it is: suppose people are forwarding X BTC per hour through a channel in one direction, and 2X BTC through it in the other direction, with all payments being 1000 sats exactly. Then if you set htlc_max_msat to 500sats on the overloaded direction, and everyone then triggers their AMP paths and sends half their payments through a slightly more expensive path, you'll be at X-vs-X BTC per hour, with balanced flows and stable channel balances. OTOH, it is relying on senders doing things that are slightly less optimal in the short term (pay higher fees) for things that benefit them only in the long term (avoid payment latency/failures due to depleted channels), and only if most people cooperate. Perhaps there's some privacy-preserving way that channel operators could throttle payments based on htlc_max_msat (and channel depletion percentage?) as well, so that cheaters are less likely to prosper? But as far as (1) goes -- this isn't actually an improvement: instead of rejecting X BTC per hour from the overloaded direction because your channel's depleted, you're now not even getting the opportunity to forward those payments and collect the corresponding fees. It's no worse for your profit margins, but it's not any better. (And it could be worse if you're throttling both sides, and only getting 0.95*X BTC per hour in both directions. But there aren't many ways you can actually do better with (1). One way is if you have a cheap way to rebalance your channels -- in that case, rebalance your channel, let it drain again, collecting fees all the while, and repeat. If rebalancing is cheaper than the fees you collect, this works great! The other way is if fees rates are expected to change -- if they're likely to go down later, then you might as well deplete your channel now, since you'll collect more fees for it now than you would later; likewise if you expect fees to up up later, then you might want to retain some balance now, so you can deplete it later. But that's a very dynamic situation, and the profits are limited -- you can only drain your channel once while waiting for fee rates to be ready to change, and your profit is going to be capped by your channel capacity times the difference in the fee rates. This approach seems *much* better than the fee rate cards idea: * you're not decreasing your channel profitability half the time in order to avoid your channel depleting * you're making routing decisions *less* dependent on internal/private state, rather than more * you're not adding much gossip/probing traffic -- you might need to refine your htlc_max_msat a few times each time you change fees, but it shouldn't be often, and this should be reducing the frequency you have to change fees anyway * you're providing a way of throttling payment traffic independent of fees -- since fees are competitive, they can have discontinuous effects where a small change to fee can cause a large change to traffic volume; but this seems like it should mostly have a proportional response, with a small decrease in htlc_max_msat resulting in a small decrease in payment volume, and conversely. Much better for stability/optimisation! Cheers, aj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev