Faster FeeModderByBalance Response

[ksedgwic]

The FeeModderByBalance module increases the fee rates as the channels balance changes from all outgoing to all incoming. When an outgoing channel is freshly created it's fee rate should be low. After the majority of the balance is spent it should be much higher.

This is important because it helps keep the channels in balance; encouraging routing through channels w/ lots of spendable balance and discouraging routing through channels that are saturated (all spent to peer).

Currently CLBOSS modifies the announced fee rates as the balance changes, but there is evidence that it doesn't do it fast enough. A newly created channel will be entirely spent (balance sent to peer) before the fee has a chance to adjust.

This "leaves money on the table" since we route at a lower effective feerate than if we were adjusting more rapidly.

There is reference to the strategy in the source WRT the feeadjuster plugin:

clboss/Boss/Mod/FeeModderByBalance.cpp

Lines 25 to 39 in 5aa184e

	This module is inspired by `feeadjuster` plugin of darosior in
	https://github.com/lightningd/plugins
	There are some major differences.
	* This runs at the schedule determined by the `Boss::Mod::ChannelFeeManager`,
	whereas the `feeadjuster` runs at every forward notification.
	* The `feeadjuster` behavior should get smoothed out by `lightningd`,
	which will defer actual fee update broadcasts, effectively merging
	multiple updates together.
	* This bins more strictly in order to reduce the accuracy of the
	fee-to-amount mapping.
	The fee set is in the middle of the bin and bins are set regularly,
	whereas `feeadjuster` will create a bin centered at the current balancing
	point with fuzzy boundaries.

Consider modifying the fee more rapidly. It was suggested that one fee modification per block is reasonable.

Make sure to be "fuzzy" so as to not leak too much information.

[endothermicdev]

I think more rapid response would help, but like you suggest in making it fuzzy, I worry it gives away some of the channel state when it's too fast.
Another approach might be to temporarily target higher balances in a channel when it's new, and gradually change to the long-term thresholds while trying to optimize fees. I.e., maybe the original 20% threshold could be 60% (or more) when the channel is new. Some new outbound channels will immediately experience high demand. It's better to not give that outbound away for too cheap even if it means some channels sit relatively idle for a bit when new. Would that make it easier or harder to discover appropriate pricing before the outbound liquidity is gone?

[sj-fisher]

@endothermicdev That sounds like a good idea. I wonder if after a rebalance a (weaker?) version of this might be useful, so we don't spend money rebalancing and then someone just uses up our newly acquired outbound liquidity straight away.