Would a min_fee setting for Lightning channels make sense?
What is a
min_fee means changing the fee calculation to
max(min_fee, fee_rate * amt), potentially replacing the
base_fee. My reasoning behind this is that it prevents 0-fee payments – fees below 1 msat are currently rounded down to 0 – without setting a
How does it help?
Not setting a
min_htlc_msat makes sure that micropayments can still be routed, while not setting a
base_fee ensures a linear fee function for Pickhardt payments.
While my proposed fee function is generally not linear, it can be ensured that it always is linear in practice. I showed this in a reddit thread, responding to Rene Pickhardt. Here’s my response in full, if you don’t want to go to that reddit thread:
My idea behind
max(min_fee, fee_rate * amt)was the fact that for reasonable
fee_ratesettings, the function is linear even for relatively small payments.
More exactly, the function is linear for
fee_rate * amt >= min_fee– or equivalently
amt >= min_fee / fee_rate(let’s call this the
A wallet/node that uses your flooding algorithm – with, say, a minimum split size of 10k sats – could then heuristically ignore channels that:
- Have any base fee
- Have a
fee_ratiothat is greater than 10k sats, which should be incredibly rare
Most channels would probably have their
min_feeset to 1 msat, simply to prevent 0-fee htlcs. In my 200 ppm example, the
fee_ratiowould be 5 sats.
In fact, just 1k sats is a magic number here! When the
min_feeis 1 msat, then any channel with a nonzero
fee_ratehas a maximum
fee_ratioof 1k sats (
0.001 / 0.000001 = 1000)!
So even all the way down to 1k sat payment splits, any channel with a 1 msat
min_fee– and a nonzero
fee_rate– has a linear fee function.
Is it a good idea?
Now I would like to know if there are any fundamental issues here that I’m missing.
It seems to me that it could serve as a replacement for the (iirc arbitrary)
base_fee setting, while still allowing Pickhardt payments.