Channel fee optimization

[bitromortac]

Add update-fee command, which is meant to be invoked periodically (~every week) for channel fee optimization purposes.

The command will adjust the fee rates and optionally the base fees (they are set to zero by default) after user consent, such that the demand for liquidity of a channel is taken into account. A liquidity reserve is kept for excess demand with a fee premium.

The command aims for a weekly throughput of 100k sat per channel (configurable). The weekly throughput will be optimized for maximal fees in future work. See the readme changes for further details.

Todo:

• add description in readme
• change type annotations
• make global throughput configurable
• exempt channels from optimization via config file
• comment on initial fee setting

[C-Otto]

I don't think that once a week is enough, I'd say once every few hours is more realistic. Furthermore, I believe that channels are wildly different, which is why the throughput definition should be channel-specific (if this approach is used, at all).

[bitromortac]

I don't think that once a week is enough, I'd say once every few hours is more realistic.

This is not going to be possible for the whole of the network. If everybody does this it's putting up a lot of load on the gossip and nodes will strongly start to rate-limit. Right now, fee optimization is done over all channels for each interval, but this could be torn appart and be done on an individual basis, which is the goal once I have a watcher daemon ready.

Furthermore, I believe that channels are wildly different, which is why the throughput definition should be channel-specific (if this approach is used, at all).

Very true, but the wild difference of channels is taken into account, have a look at what the command gives you as a suggested output and compare whether it is according to your desired fee change (you don't have to apply them - you are going to be asked whether you want or not). I agree that the global throughput is just a guess here, but at least it should be configurable. I wanted to reduce the number of parameters one has to apply to a minimum. As I mentioned above, the optimal throughput has to be learned over some optimization periods, which can be then incorporated into a per-channel throughput limit.