Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-24 📝 Original message: On Thu, Sep 22, 2022 at ...
📅 Original date posted:2022-09-24
📝 Original message:
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
📝 Original message:
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