Target forwarding amount

[kroese]

I hope it is still on the todo-list to create an analyzer to determine better per channel forwarding targets for update-fees?

It feels a bit strange that very big channels have the same (absolute) target as tiny channels. Maybe it would be more logical to make the forwarding target a percentage of the channel capacity instead of an absolute amount? It's easy to implement, but Im a bit in doubt if it would provide better results or not. Was it on purpose that you used an absolute amount?

Maybe we can use this issue to track the progress on improving this part of update-fees.

[bitromortac]

Hey, sorry for my late reply, I chose it in this way as to treat all channels "equally". If you would have many small channels and only a big one, where you would allow for lots of traffic, it would influence the small ones heavily if you would set a percentage. The idea was to create equal in- and outflow through the channels.

Of course, the optimal throughput is channel dependent and should be learned over time by observing the volume dependent on the fees. I haven't received too much feedback on the fee update feature yet, do you still use it, is it working for you? The historic fees and volumes are tracked in a json file to be used in the future. I tried to work on finding optimal fee rates by fitting the price-revenue curve, but so far it turned out to be very varying/fluctuating such that describing it with a model is rather hard. Right now it is a bit on pause, but I'll probably do more research on it soon.

[kroese]

Yes, I run the update-fees on a daily schedule (instead of weekly). It seems to work fine.

The only thing I am a bit doubtful about is that it keeps increasing the fees for channels that have no outbound liquidity. In your documentation you describe the reason for this as "to create a buffer". But I don't really understand the purpose of this buffer. The downside is that when there is finally traffic in the opposite direction, it will take several days to bring back down the fees to a reasonable level (because they are only halved each run). It would be nice if they would be lowered quicker as soon as it detects the buffer is no longer needed.

[bitromortac]

Cool, thanks for the feedback! Right, if there's no outbound liquidity, the fee rate will rise but very slowly (5% at max). Imagine you entered that state of depletion in a process where you had several forwardings with a few fee adjustments (I'm not talking about a freshly opened channel here). In that scenario, theoretically you should learn the fee rate that was roughly enough to throttle the demand to the target volume, but not quite, such that the channel entered that state of depletion. Increasing the fee rate slowly means that economically we discourage traffic over the channel, but in a way to be able to remember what fees were charged before, such that we can enter into operational state again with a lower fee (the fee rate serves as a memory because we only increased slowly). By increasing the fees already before the channel gets exhausted (this currently happens when there's 500ksat or less outbound liquidity), we create a buffer for when there's excess demand, which causes less failures overall and is able to harvest these high-fee forwarding spikes. If we would lower the fee rates even more in a single step (more than 50%) as you suggest, it could happen that we drastically undercharge. But I agree, this also need more research on how large the adjustments should be percentage-wise.

[kroese]

@bitromortac Okay, I understand the rationale a bit better now.

But my problem is the following: I run the script on a daily schedule, and I have a lot of exhausted channels. So over time all their fees will creep up to over 3000 ppm. Then when there is a finally a transaction which balances the channel again, it takes two weeks for the channel to return to a reasonable fee of 100 ppm. This makes channels that are underused even less used.

Maybe the solution would be to have a fixed upper-bound on the fee for an exhausted channel so it never reaches 3000+. Or otherwise an option to disable this exhaustion buffering.

[bitromortac]

I see that, but I guess that most of the channels that are able to creep up to these high values are nodes that strongly attract your liquidity (i.e. they are sinks or outbound-heavy nodes). If there would be significant counter-flow, the channel shouldn't be in that high-fee state in the first place?

One way of limiting the max fee rate is --max-fee-rate, which you probably saw, but then this applies to all channels (also the high-earning ones). I think it's difficult to distinguish those peers from the depleted ones. Perhaps you could give me a trace of (made-up) events how you would like the fee to behave for different liquidity situations, such that I can better understand the use case.

[kroese]

Sorry I forgot about the --max-fee-rate parameter, I will use that. It doesn't matter that it applies to all channels.