Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[Anthony Towns]

On Thu, Sep 29, 2022 at 12:41:44AM +, ZmnSCPxj wrote:
> > I get what you're saying, but I don't think a "stock of liquidity"
> > is a helpful metaphor/mental model here.
> > "Liquidity" usually means "how easy it is to exchange X for Y" -- assets
> > for cash, etc; but for lightning, liquidity is guaranteed by being
> > able to drop to chain. Likewise, "running out of stock" isn't usually
> > something that gets automatically fixed by someone else coming in and
> > buying something different.
> Semantics.
> You got what I am saying anyway.

Semantics are important. If you choose the wrong analogies, you'll jump
to the wrong conclusions, which I think you're doing here.

> So let me invent a completely new term derived from my local `/dev/random`, 
> "IPpvHg".

If you're going to make up words, at least make them pronouncable...
apt-get install pwgen; pwgen -0A maybe. But there's no need to make
up words; these aren't completely novel concepts, and existing terms
describe the concepts pretty well.

> A patient and rich forwarding node can buy out the IPpvHg stock of many 
> cheaper nodes,

I just spent a lot of words explaining why I disagree with that claim.
Restating it doesn't really seem constructive.

> and that I think is what we are mostly seeing in the network.

I don't really agree. I think we're seeing a combination of unbalanced
overall flows due to an insufficiently circular economy (which would
perhaps be eased by more custodial wallets/exchanges supporting lightning)
and the combination of a lack of any way to limit channel flow other
than raising fees and an inability to dynamically change fees on a
minute-by-minute timescale.

> > (Also, you don't earn 0 profit on an imbalanced channel; you're just
> > forced to stop accepting some txs. Every time you forward $1 in the
> > available direction, you become able to forward another $1 back in the
> > saturated direction; and you earn fees on both those $1s)
> But that is based on the existence of a stock of IPpvHg in another channel.

No, it's not. It applies even if there is only one channel in the
entire network (though I guess that channel would have to be between two
custodial entities, or there wouldn't be any point charging fees in the
first place).

> Actual forwarding node operators classify their peers as "mostly a source" 
> and "mostly a drain" and "mostly balanced", they want CLBOSS to classify 
> peers similarly.

"mostly a source" should trigger rate limiting in one direction, "mostly
a drain" should trigger rate limiting in the other. Both should only be
true briefly, until the rate limiting kicks in and the channel becomes
"mostly balanced".

That's still the case even if the rate limiting is "oops, one side of
the channel has ~0 balance".

> > I think it's better to think in terms of "payment flow" -- are you
> > forwarding $5/hour in one direction, but $10/hour in the other? Is
> > that an ongoing imbalance, or something that evens itself out over time
> > ($120/day in both directions)?
> It is helpful to notice that the channel balance is the integral of the sum 
> of payment flows in both directions.

The channel balance is the sum of the initial balance and all payments,
sure. No need to add an integral in there as well. For a successful,
long lasting channel, sum(incoming payments) and sum(outgoing payments)
will be much greater than the balance, to the point where the balance
is just a rounding error by comparison.

> This is why actual forwarding node operators are obsessed with channel 
> balance.
> They already *are* thinking in terms of payment flow, and using an analytical 
> technique to keep track of it: the channel balance itself.

This is exactly backwards: you don't monitor your profits by looking at
the rounding errors, you monitor your profits by looking at your sales.

If you've forwarded $100,000 in one direction, and $100,200 in the other
direction, you care about the $200,200 total that you were charging fees
on, not the $200 net delta that it's made to your channel balance.

> > Once you start in that direction, there's also a few other questions
> > you can ask:
> > 
> > * can I get make more revenue by getting more payment flow at a
> > lower fee, or by charging a higher fee over less payment flow?
> 
> As I pointed out, if you sell your stock of IPpvHg at too low a price point, 
> other forwarding nodes will snatch up the cheap IPpvHg, buying out that stock.
> They can then form an effective cartel, selling the stock of IPpvHg at a 
> higher price later.

No; changing your fee rate isn't about messing with other people's
channels, it's about encouraging more use of lightning overall.  For
example, if you're charging a base_fee of 1sat per HTLC, then dropping
that to 0sat might reduce fees from existing traffic, but maybe it will
allow you to forward so many micropayments or AMP payments that it's
wortwhile anyway.

The lightning network is tiny; if you're constantly thinking about how
to steal what 

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[ZmnSCPxj via Lightning-dev]

Good morning aj,

> > Forwarding nodes sell liquidity.
> > If a forwarding node runs out of stock of liquidity (i.e. their channel is 
> > unbalanced against the direction a payment request fails) they earn 0 
> > profit.
> 
> 
> I get what you're saying, but I don't think a "stock of liquidity"
> is a helpful metaphor/mental model here.
> 
> "Liquidity" usually means "how easy it is to exchange X for Y" -- assets
> for cash, etc; but for lightning, liquidity is guaranteed by being
> able to drop to chain. Likewise, "running out of stock" isn't usually
> something that gets automatically fixed by someone else coming in and
> buying something different.

Semantics.
You got what I am saying anyway.

So let me invent a completely new term derived from my local `/dev/random`, 
"IPpvHg".

When your channel is imbalanced against a particular direction, you cannot 
forward against the balance.
In that case, we say "you have insufficient stock of IPpvHg".

A forwarding node is in the business of selling IPpvHg.

If a forwarding node sets the price of its IPpvHg too low, another forwarding 
node, one which is more patient, can buy out its stock of IPpvHg to add to its 
own stock of IPpvHg.

A patient and rich forwarding node can buy out the IPpvHg stock of many cheaper 
nodes, and that I think is what we are mostly seeing in the network.

> (Also, you don't earn 0 profit on an imbalanced channel; you're just
> forced to stop accepting some txs. Every time you forward $1 in the
> available direction, you become able to forward another $1 back in the
> saturated direction; and you earn fees on both those $1s)

But that is based on the existence of a stock of IPpvHg in another channel.

Actual forwarding node operators classify their peers as "mostly a source" and 
"mostly a drain" and "mostly balanced", they want CLBOSS to classify peers 
similarly.
Their stock of IPpvHg is getting depleted from "mostly a drain" peers, and the 
stock of IPpvHg they get from "mostly a source" peers, which they get in 
compensation, is less valuable.

Which is the whole point: there is a price to IPpvHg, and that should be 
reflected in the feerates your forwarding node should publish.

> I think it's better to think in terms of "payment flow" -- are you
> forwarding $5/hour in one direction, but $10/hour in the other? Is
> that an ongoing imbalance, or something that evens itself out over time
> ($120/day in both directions)?

It is helpful to notice that the channel balance is the integral of the sum of 
payment flows in both directions.
This is why actual forwarding node operators are obsessed with channel balance.
They already *are* thinking in terms of payment flow, and using an analytical 
technique to keep track of it: the channel balance itself.

> 
> Once you start in that direction, there's also a few other questions
> you can ask:
> 
> * can I get make more revenue by getting more payment flow at a
> lower fee, or by charging a higher fee over less payment flow?

As I pointed out, if you sell your stock of IPpvHg at too low a price point, 
other forwarding nodes will snatch up the cheap IPpvHg, buying out that stock.
They can then form an effective cartel, selling the stock of IPpvHg at a higher 
price later.

> * if I had a higher capacity channel, would that let me tolerate
> a temporarily imbalanced flow over a longer period, allowing me
> to forward more payments and make more fee revenue?
> 
> If you want to have a long running lightning channel, your payment flows
> will always be balanced. That might be through luck, it might be through
> clever management of channel parameters, but if it's not through those,
> it'll be because your channel's saturated, and you're forced to fail
> payments.
> 
> Ultimately, over the entire lifetime of a lightning channel, the only
> imbalance you can have is to either lose the funds that you've put in,
> or gain the funds your channel partner put in.
> 
> That is something you could sensibly model as a stock that gets depleted
> over time, if your payment flows are reliably unbalanced in a particular
> direction. For example, consider a channel that starts off with $100k in
> funds and has a $5k imbalance every day: after 20 days, you'll have to
> choose between failing that $5k imbalance (though you could still route
> the remaining balanced flows), or between rebalancing your channels,
> possibly via on-chain transactions. Does the fee income from an additional
> $100k of imbalanced transactions justify the cost of rebalancing?
> 
> You can calculate that simply enough: if the on-chain/rebalance cost is
> $300, then if you were getting a fee rate of more than 0.3% ($300/$100k),
> then it's worth paying for the rebalance.
> 
> But if "lifetime drain" is the dominant factor, you're reducing
> lightning to the same performance as one-way payment channels: you move
> the aggregate payments up to the channel capacity, and then close the
> channel. If you get balanced payment flows, that 

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[Anthony Towns]

On Tue, Sep 27, 2022 at 12:23:38AM +, ZmnSCPxj via Lightning-dev wrote:
> All monetisation is fee-based; the question is who pays the fees.

This isn't true. For example, if you can successfully track the payments
you route, you can monetize by selling data about who's buying what
from whom. (Unless you meant it in some trivial sense, I guess, like
"all monetisation is money-based; the question is who pays the money")

> In particular, discussing with actual forwarding node operators reveals
> that most of them think that CLBOSS undercuts fees too much searching
> a short-term profit, quickly depleting its usable liquidity in the
> long term.
> In short, they want CLBOSS modified to raise fees and preserve the
> liquidity supply.
> This suggests to me that channel saturation due to being cheaper by
> 0.0001% is not something that will occur often,

That seems a bit of a backwards conclusion: "undercutting fees depletes
liquidity" therefore "channel saturation due to offering cheaper fees
seems unlikely" -- channel saturation *is* depleted liquidity...

On Wed, Sep 28, 2022 at 02:07:51AM +, ZmnSCPxj via Lightning-dev wrote:
> Forwarding nodes sell liquidity.
> If a forwarding node runs out of stock of liquidity (i.e. their channel is 
> unbalanced against the direction a payment request fails) they earn 0 profit.

I get what you're saying, but I don't think a "stock of liquidity"
is a helpful metaphor/mental model here.

"Liquidity" usually means "how easy it is to exchange X for Y" -- assets
for cash, etc; but for lightning, liquidity is guaranteed by being
able to drop to chain. Likewise, "running out of stock" isn't usually
something that gets automatically fixed by someone else coming in and
buying something different. 

(Also, you don't earn 0 profit on an imbalanced channel; you're just
forced to stop accepting some txs. Every time you forward $1 in the
available direction, you become able to forward another $1 back in the
saturated direction; and you earn fees on both those $1s)

I think it's better to think in terms of "payment flow" -- are you
forwarding $5/hour in one direction, but $10/hour in the other? Is
that an ongoing imbalance, or something that evens itself out over time
($120/day in both directions)?

Once you start in that direction, there's also a few other questions
you can ask:

 * can I get make more revenue by getting more payment flow at a
   lower fee, or by charging a higher fee over less payment flow?

 * if I had a higher capacity channel, would that let me tolerate
   a temporarily imbalanced flow over a longer period, allowing me
   to forward more payments and make more fee revenue?

If you want to have a long running lightning channel, your payment flows
will *always* be balanced. That might be through luck, it might be through
clever management of channel parameters, but if it's not through those,
it'll be because your channel's saturated, and you're forced to fail
payments.

Ultimately, over the *entire* lifetime of a lightning channel, the only
imbalance you can have is to either lose the funds that you've put in,
or gain the funds your channel partner put in.

That *is* something you could sensibly model as a stock that gets depleted
over time, if your payment flows are reliably unbalanced in a particular
direction. For example, consider a channel that starts off with $100k in
funds and has a $5k imbalance every day: after 20 days, you'll have to
choose between failing that $5k imbalance (though you could still route
the remaining balanced flows), or between rebalancing your channels,
possibly via on-chain transactions. Does the fee income from an additional
$100k of imbalanced transactions justify the cost of rebalancing?

You can calculate that simply enough: if the on-chain/rebalance cost is
$300, then if you were getting a fee rate of more than 0.3% ($300/$100k),
then it's worth paying for the rebalance.

But if "lifetime drain" is the dominant factor, you're reducing
lightning to the same performance as one-way payment channels: you move
the aggregate payments up to the channel capacity, and then close the
channel. If you get balanced payment flows, that allows you to cancel
out 30,000 $1 transactions against 1,000 $30 transactions, and maintain
the channel indefinitely, with all the off-chain scaling that implies.

> If a forwarding node finds a liquidity being sold at a lower price than they 
> would be able to sell it, they will buy out the cheaper stock and then resell 
> it at a higher price.
> This is called rebalancing.

All that does is move the flow imbalance to someone else's channel;
it doesn't improve the state of the network.

There definitely are times when that makes sense:

 * maybe the channel's run by "dumb money" that will eat the fee for
   closing on-chain, so you don't have to

 * maybe you have secret information about the other channel, allowing
   you to route through it for cheaper than the general public

 * maybe you and they 

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[ZmnSCPxj via Lightning-dev]

Good morning aj, Rene, and all,

So let me discuss a little more about how I model the forwarding nodes.

Forwarding nodes want to maximize profit.

Forwarding nodes sell liquidity.

If a forwarding node runs out of stock of liquidity (i.e. their channel is 
unbalanced against the direction a payment request fails) they earn 0 profit.

If a forwarding node finds a liquidity being sold at a lower price than they 
would be able to sell it, they will buy out the cheaper stock and then resell 
it at a higher price.
This is called rebalancing.
In particular:

* Other economic activity is likely to be "has to happen at a particular time".
  * The intuition here is that people are not going to pay until they become 
interested in purchasing a product, and only then will they actually send out 
an HTLC.
* Rebalances (i.e. hostile takeover bids of cheap liquidity) are "can happen at 
any time".
* Thus, rebalances are likely to occur "first", because they can happen at any 
time, and can be done right now, whereas payments will need to wait until 
somebody somewhere is interested in paying.
* Thus, channels advertising low fees are likely to have their liquidity bought 
out by patient forwarding nodes.

The above implies that any "payment size distribution" can, and *will*, be 
manipulated by forwarding nodes out to buy out cheap liquidity.
If you introduce an artificial impediment and say "I will only accept payment 
sizes below N millisats", and then go "I will #zerofeerouting guy", then a 
forwarding node will just split their rebalance into quanta of N millisats and 
make a spike in the payment size distribution and drain your channel anyway, so 
that they can turn around and resell the liquidity at a higher price later.

This also suggests to me that fees being paid by out-of-band means (i.e. 
"monetizing outside of the Lightning forwarding fees") is likely to fail, 
because forwarding nodes will exploit that and do a hostile takeover of the 
cheap liquidity.
i.e. #zerofeerouting will never be a reliable forwarding node, because all the 
other forwarding nodes will be taking their liquidity for cheap long before you 
think to make a payment through them.

Rebalances cannot be differentiated from payments unless you force publication 
of source and destination (and even if you forced that, people can lie about 
who the *real* source and *real* destination are, so why bother).
And rebalances are going to target cheap liquidity and will avoid any non-fee 
valves you impose.

Invisible hand wins, yo.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[ZmnSCPxj via Lightning-dev]

Good morning aj,

> > Basically, the intuition "small decrease in `htlc_max_msat` == small 
> > decrease in payment volume" inherently assumes that HTLC sizes have a flat 
> > distribution across all possible sizes.
> 
> 
> The intuition is really the other way around: if you want a stable,
> decentralised network, then you need the driving decision on routing to
> be something other than just "who's cheaper by 0.0001%" -- otherwise
> everyone just chooses the same route at all times (which becomes
> centralised towards the single provider who can best monetise forwarding
> via something other than fees), and probably that route quickly becomes
> unusable due to being drained (which isn't stable).

All monetisation is fee-based; the question is who pays the fees.
Certainly gossiped feerates will work less effectively if fees are paid via 
another mechanism.

In particular, discussing with actual forwarding node operators reveals that 
most of them think that CLBOSS undercuts fees too much searching a short-term 
profit, quickly depleting its usable liquidity in the long term.
In short, they want CLBOSS modified to raise fees and preserve the liquidity 
supply.
This suggests to me that channel saturation due to being cheaper by 0.0001% is 
not something that will occur often, as most operators will settle to a feerate 
that maximizes their earnings per unit liquidity they can provide, not trying 
to undercut everyone.

In particular, the fact that rebalancing already exists as part of the network 
protocol means that anyone trying to undercut will find their liquidity being 
bought out by more patient operators, who are willing to sacrifice short-term 
profits for long-term consistent earnings.

In short, the market will fix itself once we have more rational automated 
actors in place (i.e. not CLBOSS).
Indeed, price signals are always places where you should pay attention to 
whether you need more of a good or not.

But maybe I am just modelling everything incorrectly.
Certainly the fact that fees can be paid by somebody else other than senders 
can make gossiped feerates (which are the sender-paid feerates) less effective.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[Anthony Towns]

On Mon, Sep 26, 2022 at 01:26:57AM +, ZmnSCPxj via Lightning-dev wrote:
> > > * 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!

> > This may depend on what gets popular for sender algorithms.
> > Senders may quantize their payments, i.e. select a "standard" value and 
> > divide all payments into multipath sub-payments of this value.

I don't think that's really the case. 

One option is that you quantize based on the individual payment -- you
want to send $100, great, your software splits it into 50x $2 payments,
and routes them. But that doesn't have an all or nothing effect: if you
reject anything over $1.99, then instead of routing 1/50th of payments
up to $100, you're routing 1/50th of payments up to $99.50.

The other approach is to quantize by some fixed value no matter what the
payment is (maybe for better privacy?). I don't think that's a good idea
in the first place -- it trades off maybe a small win for your privacy
for using up everyone else's HTLC slots -- but if it is, it'll need to be
quite a small value so as not to force you to round up the overall payment
too much, and to allow small payments in the first place. But in that case
most channels will have their html_max_msat well above that value anyway.

> Basically, the intuition "small decrease in `htlc_max_msat` == small decrease 
> in payment volume" inherently assumes that HTLC sizes have a flat 
> distribution across all possible sizes.

The intuition is really the other way around: if you want a stable,
decentralised network, then you need the driving decision on routing to
be something other than just "who's cheaper by 0.0001%" -- otherwise
everyone just chooses the same route at all times (which becomes
centralised towards the single provider who can best monetise forwarding
via something other than fees), and probably that route quickly becomes
unusable due to being drained (which isn't stable).

(But of course, I hadn't had any ideas on what such a thing could be,
otherwise I'd have suggested something like this earlier!)

So, to extend the intuition further: that means that if using
htlc_max_msat as a valve/throttle can fill that role, then that's a reason
to not do weird things like force every HTLC to be 2**n msats or similar.

If there is a conflict, far better to have a lightning network that's
decentralised, stable, and doesn't require node operators to spy on
transactions to pay for their servers.

It's not quite as bad as you suggest though -- the payment sizes
don't need to have a flat distribution, they only need to have a
smooth/continuous distribution.

> * Coffee or other popular everyday product may settle on a standard price, 
> which again implies a spike around that standard price.

Imagine the price of coffee is $5, and you find three potential paths 
to pay for that coffee:

  Z -> A -> X
  Z -> B -> C -> X
  Z -> B -> D -> X

(I think you choose both the fee and max_msat for Z->A and Z->B hops,
so we'll assume they're 0%/infinite, respectively)

Suppose the fee on AX is 0.01%, and the total fee for BCX is 0.02%
and the total fee for BDX is 0.1%.

If AX's max_msat is $5, they'll get the entire transaction. If it's
$4.99, you might instead optimise fees by doing AMP: send $4.99 through
AX and $0.01 through BCX, for a total fee rate of 0.01002%.

If everyone quantizes at 10c (500sat?) instead of 1c (50sat?) or lower
then that just means instead of getting maybe a 0.2% reduction in payment
flow, AX gets a 2% reduction in payment flow.

Likewise, if AX's max_msat is $1, BCX's max_msat is $3, and BDX's max_msat
is $20, then you split your payment up as $1/$3/$1 and pay a fee of
0.034%. Meanwhile AX's payment flow has been reduced by perhaps 80%
(if everyone's buying $5 coffees), and BCX's by perhaps 25% (from $4 to
$3), allowing them to maintain balanced channels.

> So the reliability of `htlc_max_msat` as a valve is dependent on market 
> forces, and may be as non-linear as feerates, which *are* the sum total of 
> the market force.

No: without some sort of external throttle, fees have a tendency to be all
or nothing. If there's no metric other than fees, why would I ever choose
to pay 0.02% (let alone 0.1%!) in fees? And if a new path comes along
offering a fee rate of 0.00999% fees, why would I continue paying 0.01%?

Even if everyone does start quantizing their payments -- and does so with
an almost 6 order of magnitude jump from 1msat to 500sats -- you're only
implying traffic bumps of perhaps 2% when tweaking parameters that are
near important thresholds, rather than 100%.

> Feerates on the other hand 

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[ZmnSCPxj via Lightning-dev]

Good morning again aj, and Rene,

> Good morning aj, and Rene,
> 
> > * 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!
> 
> 
> This may depend on what gets popular for sender algorithms.
> 
> Senders may quantize their payments, i.e. select a "standard" value and 
> divide all payments into multipath sub-payments of this value.
> 
> * Simplifies the computation of base fee when using a min-cost solver.
> * Simplifies the design of splitting/merging decisions if not using a 
> min-cost solver.
> * Improves privacy once we have PTLCs (if most senders use the same standard 
> value, it is much harder to figure out if two sub-payments, with 
> approximately the same standard quantum, belong to the same payment or not).
> 
> If so, then we expect a large discontinuity for the `htlc_max_msat` vs 
> `htlcs_sent` curve around whatever selected quantum there is.
> If you set `htlc_max_msat` below this quantum your expected number of 
> payments forwarded will drop to near 0, but a little above that and you might 
> very well saturate since all payments are quantized anyway.
> 
> At least fees gets you basic economics of supply and demand, and is a natural 
> throttle in all markets, including liquidity markets.

Basically, the intuition "small decrease in `htlc_max_msat` == small decrease 
in payment volume" inherently assumes that HTLC sizes have a flat distribution 
across all possible sizes.
The `htlc_max_msat` vs `payment_volume` curve is basically the integral of the 
distribution of HTLC sizes.
But:

* As above, senders might quantize, and if some standard quantum becomes 
popular, the distribution is really a spike around the standard quantum, and 
there is a massive discontinuity there.
* Coffee or other popular everyday product may settle on a standard price, 
which again implies a spike around that standard price.

So the reliability of `htlc_max_msat` as a valve is dependent on market forces, 
and may be as non-linear as feerates, which *are* the sum total of the market 
force.

Feerates on the other hand are always going to be something that senders 
optimize for, because obviously senders will have a maximum amount they will be 
willing to pay in fees (as before, the intuition here is that the maximum fee 
senders are willing to pay is equivalent to the difference in subjective value 
between the millisatoshis they are sending and the service/product they are 
purchasing).
Whatever future sender algorithms are devised, feerates will still work 
consistently as a valve, whreas `htlc_max_msat` may fail in a future where 
sender algorihms quantize the payments around some standard quantum for privacy 
and ease-of-implementation purposes.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[ZmnSCPxj via Lightning-dev]

Good morning aj, and Rene,

> * 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!

This may depend on what gets popular for sender algorithms.

Senders may quantize their payments, i.e. select a "standard" value and divide 
all payments into multipath sub-payments of this value.

* Simplifies the computation of base fee when using a min-cost solver.
* Simplifies the design of splitting/merging decisions if not using a min-cost 
solver.
* Improves privacy once we have PTLCs (if most senders use the same standard 
value, it is much harder to figure out if two sub-payments, with approximately 
the same standard quantum, belong to the same payment or not).

If so, then we expect a large discontinuity for the `htlc_max_msat` vs 
`htlcs_sent` curve around whatever selected quantum there is.
If you set `htlc_max_msat` below this quantum your expected number of payments 
forwarded will drop to near 0, but a little above that and you might very well 
saturate since all payments are quantized anyway.

At least fees gets you basic economics of supply and demand, and is a natural 
throttle in all markets, including liquidity markets.

Regards,
ZmnSCPxj

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[Anthony Towns]

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

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[René Pickhardt via Lightning-dev]

Dear Matt and Lightning developers,

those are excellent and important questions that I should probably have
addressed more explicitly in the article / ml-post! Let me add what I
currently know and begin with your second question as I think I think the
answer will be more objective / verifiable while my response to the gossip
question is a bit more speculative at this point:

On Fri, Sep 23, 2022 at 10:43 AM Matt Corallo 
wrote:

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?
>

We know from information theory that the distribution with the highest
entropy is the uniform distribution [1] which in the context of a channel
with capacity of `c` means `log(c+1)` bits as shown in [2].

Now if a given drain leads to a pair of `htlc_maximum_msat` one could in
deed also go the other way around and look at the pair of
`htlc_maximum_msat` and estimate the *past* drain. And of course also the
(the non uniform) liquidity distribution from the past. Note that now with
the better `htlc_maximum_msat` pair the distribution should be closer to
uniform again which is actually best from an information theoretic point of
view as this maximizes the entropy in the channel.

I have just created and uploaded a small python script / notebook [3]  from
which we can see for example how much information about the shape of the
past liquidity distribution we would learn if we could induce from the
`htlc_maximum_msat` pair that the drain was 0.75. So from the notebook I
quote:

Assume we learnt a drain of 0.75
=
Entropy of uniform: 20.00 bits.
Entropy of the channel with drain: 19.17 bits
Information gain: 0.83 bits


Yes we learnt less than 1 bit of information by knowing the shape of the
distribution from the last payments. This much is learnt by a single probe.
Given that we expect our payment failure rates to drop by an order of
magnitude and the fact that I could probably learn the drain from the on
chain signal or gossip anyway I personally would consider this information
leakage to be acceptable. But of course people may not agree with me and
just not set their `htlc_maximum_msat` flag in the proposed manner. Also it
is obvious that higher drain values produce a more heavily depleted channel
and we might learn more bits (in case of a 0.95 drain we learnt about 3
bits.)

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?
>

As written in the article I expect the setting of the valves as throtteling
devices to be rather stable as I would assume the drain on channels should
not be impacted too heavily by installing valves. This assumption is
certainly more reasonable if nodes already used min cost flow solvers to
send out payments and less reasonable if nodes still use ad-hoc splitting
heuristics and restrict their path finding on channels with sufficiently
large `htlc_maximum_msat` values for the amount of the partial payment.

In any case I expect that once the valve is in a good setting for a
particular channel / drain the setting can stay as long as the drain won't
change significantly. In general I would not expect drain on channels to
change heavily over time (though I certainly would not expect it to be
static / stable either). Certainly fee changes in the network (and other
factors) may eventually produce changes in drain on channels which would
also have to eventually be reflected in new settings for the valve.

The experimental algorithm idea that I presented in cell 12 of the original
notebook (which I also used in the privacy consideration code from above)
computes the histogram of liquidity of the last N routing requests (failed
and successful ones) that a node saw on the channel and then makes a
decision weather to open or close the valve a bit more. Using this greedy
strategy we saw in the notebook that a node could find decent values in
logarithmic many steps . So while the setup of the valve may trigger a few
gossip messages (but each one only after a sufficient amount of routing
requests have been processed) and while I expect dynamics in drain on the
channel I don't expect such adoptions should have to happen in real time or
even several times per day and put unnecessary load / spam to gossip. But I
guess we can only see this by operating nodes and probably there are some
nodes where updates occure more frequently than with other nodes.

That being said of course if the peers of a channel work together and both
exchange information / collaborate in finding a good `htlc_maximum_msat`
pair (similalry as our protocol for finding fees in a mutual close) they
will probably need less gossip messages than in the case where both nodes
independently try to find decent settings.

I am happy if people have 

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[Matt Corallo]

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/ 

[2]: 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://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

[Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

[René Pickhardt via Lightning-dev]

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/
[2]: 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://ln.rene-pickhardt.de
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev