feeadjuster: adjustment ratio tweak by 1) Funder 2) Onchain fees 3) HTLCs

[darosior]

Some adjustment methods i plan to add to the fee adjuster plugin. We should look into what ZmnSCPxj did for CLBOSS. 2) is probably the easiest one to implement.

We should think about the API for combining them, too.

[m-schmoock]

Also as @ZmnSCPxj pointed out, we may want to set/discover the base fees on a per channel basis e.g. by choosing a little less than the median of the fees from each peers other channels, as we can consider us to be somehow in competition with the 'peers of our peer'

[ZmnSCPxj]

"Funder" should probably be "Initiator" in the face of dual-funding. This is relevant since currently initiator is the one that pays onchain fee, so if you are initiator you are incentivized to charge more during high-onchain-fee period. Without dual-funding, the initiator is always the one that funded more of the channel, but post-dual-funding this is no longer a reliable way. Further, in a post-anchor commitments world, initiator is no longer the one who pays, instead only the unilateral-closer is the one who pays for the unilateral close.

This amounts to a need to also change the C-Lightning side, with the addition of unilateral_close_by_us_fee_payer and unilateral_close_by_them_fee_payer, each field can be a string "us" or "them".

• Pre-anchor-commitments and we are initiator: "unilateral_close_by_us_fee_payer": "us", "unilateral_close_by_them_fee_payer": "us"
• Pre-anchor-commitments and they are initiator: "unilateral_close_by_us_fee_payer": "them", "unilateral_close_by_them_fee_payer": "them"
• Post-anchor-commitments: "unilateral_close_by_us_fee_payer": "us", "unilateral_close_by_them_fee_payer": "them"

If we are not the fee payer for either unilateral close, we can ignore the onchain fee mostly.

Number of HTLCs is a good idea as well --- the more HTLCs already on the channel, the higher the fee we want to charge.

In CLBOSS there is a mechanism by which internal modules can register themselves as "fee modifiers" which are given a peer node ID and emit a double. Whenever CLBOSS decides to change fees (about once an hour with some randomness) all fee modifiers are invoked and the doubles are all multiplied together, then the product is then used.