Peer inbound weighted average fee strategy + Local balance proportional max_htlc_msat rule

[microlancer]

This PR is just a proof-of-concept for discussion:

1. Adds strategy for setting fees based on weighted average of peer incoming rate
2. Adds rule for setting max_htlc_msat based on local balance

The rationale for the weighted average of inbound rates of the peer is to set fees competitively based on that specific peer. I don't know how useful it is, but I thought it might be worth experimenting with. I added some other parameters to ignore overly high peer inbound rates in the calculation, and a parameter to add a premium above the calculated rate.

The rationale for the max_htlc based on local balance is to decrease the number of failed payments due to insufficient local balance errors, which could hurt the reputation of the node. Of course, this can reveal information about balances, but you can tweak the granularity a little bit. I think 3 or 4 slices would be broad enough that it's not too specific.

If this is not useful, then you can just ignore this PR.

[accumulator]

Thanks for this!

I've had many requests for setting the max HTLC size depending on local balance, but this approach using slices is actually practical.

The new strategy for weighted average fees is a nice idea, what's the use case you have in mind?

[accumulator]

It's probably best to have a hardcoded upper limit for num_slices here, so we don't spam the network (e.g. 10)

[accumulator]

alternatively, we could define a 'minimum slice size', so that large channels can use more slices than small channels (e.g. 200_000)

[microlancer]

For choosing the number of slices for large channels, would the system automatically choose from multiple policies if we set a chan.min_capacity etc. and so we could define different slice counts for different sizes?

[accumulator]

Well I was thinking along the lines of

min_slice_size = 200_000
min_slices = 10
max_slices = max(min_slices, max_value // min_slice_size)
slice_size = max_value // max_slices

so the number of slices is capped at 10 for small channels, or higher if the channel capacity allows for more.

[microlancer]

The new strategy for weighted average fees is a nice idea, what's the use case you have in mind?

My idea is that the market produces some level of intelligence which can be a good starting point for fees. Popular destinations with expensive inbound are probably that way for a reason, so rather than just making up some random rate for your own channel to that peer, you can start from the average.

I've noticed that really popular nodes acting as sinks tend to have higher inbound fees, and people are still willing to pay for them. I think some people will want to try the strategy of competing against other people who have liquidity towards the peer, and have a rate that is slightly higher or lower than the others.

Of course, it kind of requires a lot of testing anyways to see if it's actually useful, but like I said maybe it's a better starting point or rate decision than simply "treat all destinations the same" policy. It adds another dimension.

[accumulator]

The new strategy for weighted average fees is a nice idea, what's the use case you have in mind?

My idea is that the market produces some level of intelligence which can be a good starting point for fees. Popular destinations with expensive inbound are probably that way for a reason, so rather than just making up some random rate for your own channel to that peer, you can start from the average.

I've noticed that really popular nodes acting as sinks tend to have higher inbound fees, and people are still willing to pay for them. I think some people will want to try the strategy of competing against other people who have liquidity towards the peer, and have a rate that is slightly higher or lower than the others.

Of course, it kind of requires a lot of testing anyways to see if it's actually useful, but like I said maybe it's a better starting point or rate decision than simply "treat all destinations the same" policy. It adds another dimension.

I misread the patch earlier, thinking it calculated average inbound fees for your own node, but I see now that you calculate the average inbound fees for the remote node. Pretty cool, as you can indeed put yourself in a competitive spot relative to the other inbounds for that node.

Thanks for the clarification.

[microlancer]

I'm testing the average inbound fee rate on my node to see how it goes. It might not be as useful as I thought. I'll try it for a while and post my findings here.

[microlancer]

I think this feature might be more useful not alone, but combined with the other rules which adjust based on local liquidity. So, rather than having a fixed range say 0 - 1000 ppm for all channels, and rather than having a custom range manually added per channel, you could use this to detect a good range automatically for each channel.

So let's say the average inbound ppm is 200 ppm for remote node A and 800 ppm for remote node B.

It doesn't make sense to have the same fixed range for both, so you can say automatically 0 - 400 ppm is the range for A and 0 - 1600 is the range for B.

Then, as the local balance goes higher or lower, the rules can set a proportional ppm according to the appropriate ranges for A and B. And you can have charge-lnd do this automatically for all your channels, rather than manually calculate it, which is even more painful when you think about remote inbound situation changing day-to-day or week-to-week anyways. You wouldn't want to constantly monitor every remote peer's inbound situation manually.

What do you think?

[microlancer]

I've updated the branch to now be proportional. I'm testing this on my node to see how well it performs. I've also renamed a bunch of things to try to make it clearer/simpler.

Strategy name: proportional_peer_inbound (it's like proportional, but with a peer inbound twist)

Properties:

• min_fee_ppm (just like the others)
• max_fee_ppm (just like the others)
• fee_avg_calc_cutoff_ppm (calculation cutoff, kind of a weird name)
• avg_fee_ppm_multiplier (scales the calculated avg_fee)
• upper_fee_ppm_multiplier (sets the upper bound for the proportional range)

Notice the difference between max and upper. The max sets a hard limit. It will never go above this value. The upper is a dynamic setting, since the upper limit is a range that starts from the average point. They conceptually serve two different purposes.

[microlancer]

After testing for a while, I think this fee strategy is interesting but not extremely useful.

The average inbound fee rates for peers is kind of all over the place for me. For some channels, the average is way too low, and for others, way too high. The proportional method together with the average helps somewhat, but the ultimate goal is discovering an optimal fee rate and this method "might" find it, but it tends to flop around the average fee too wildly.

I'm going to focus on a new fee strategy that I think will work better for me based on my experience with this one. Instead of assuming the average is good, I will use an incremental discovery fee based on flow rate. I see there's already a strategy that considers flow using chan.activity_period and parameters that will match based on activity. But, the fees are static.

Instead, I will set up a strategy that incrementally increases/decreases the ppm based on a target ideal flow rate (or forwarding attempt rate). In other words, find the ppm that doesn't drain the channel too fast, nor does it stall the channel being too slow.

I'll submit that PR separately and evaluate the difference.