Tweaking the feerate security margin

[cdecker]

When forwarding an HTLC the funder needs to ensure that it can at
least add one more HTLC. This is the result of LN#728, which aims to
protect a channel to get into a mode where no new HTLC can be added,
not even by the fundee to rebalance the channel (due to feerate
spiking causing the commitment TX fee to no longer be payable by the
funder).

CLN is trying to be secure even against larger feerate spikes, by
being very pessimistic and assuming up to a 100% feerate spike (using
200% current feerate to determine whether adding an HTLC is safe or
not).

I would argue that for low-fee environments the 100% security margin
is justified, since the likelihood of 2 * 1sat/vbyte is much more
likely than 2 * fee ATH, but I would linearize this buffer to reduce
it relative to the absolute fee as the feerate grows.

My proposal would be to:

1. Take today's fee ATH: maxfeerate
2. Use 1sat/vbyte as minfeerate
3. Compute the current feerate margin to use as the following: 1 - min(x - minfeerate, maxfeerate)/(maxfeerate * 1.1). This results
   in a 2x current feerate close to the minfeerate, smoothly
   discounted until we get to maxfeerate at which point we just
   take a 10% margin.

The idea here is that close to the lower end where feerates are likely
to increase from, the multiplier is still the current 2x. Closer to
the historical maximum feerate we only apply a 10% margin, as the fees
are much less likely to increase further. The place to apply this
would be the code line, where we replace the 2 constant with the
margin computation.

I'm currently trying to reproduce this in a test to verify the fix
works as expected, and some historical analysis on max feerates to use
could further inform the 3 variables in play here:

• Starting slope (2)
• Final slope (1.1)
• Historical max feerate (41234perkw, taken from the original issue)

Additional information

In case somebody may be wondering what running into this issue looks
like, here are the relevant log lines:

2024-01-01T11:33:18.422Z DEBUG   03d6f117b93d0eb1c440de5549cc4f48253f94dfdcab5f92a3199167323ac05016-channeld-chan#1672: Adding HTLC would leave us only 51840000msat: we need 60531sat for another HTLC if fees increase by 100% to 41234perkw
2024-01-01T11:33:18.423Z DEBUG   03d6f117b93d0eb1c440de5549cc4f48253f94dfdcab5f92a3199167323ac05016-channeld-chan#1672: Adding HTLC 0 amount=2500000msat cltv=824005 gave CHANNEL_ERR_CHANNEL_CAPACITY_EXCEEDED
2024-01-01T11:33:18.423Z DEBUG   03d6f117b93d0eb1c440de5549cc4f48253f94dfdcab5f92a3199167323ac05016-channeld-chan#1672: REPLY WIRE_CHANNELD_OFFER_HTLC_REPLY with 0 fds

[cdecker]

And since I'm at it, here's a plot comparing the old feerate margin to the new feerate margin:

The excess fee we're paying at various feerates is given by the difference between the feerate and the percent line for the current behavior, and as the difference between feerate and smoothed for this proposal. Notice that both start with a 200% feerate margin, but then the fixed percentage just grows much quicker, whereas the smoothed one converges to 10% margin for higher values.