# Would a min_fee setting for Lightning channels make sense?

## What is a `min_fee`?

Having 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 `min_htlc_msat` or `base_fee`.

## 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 `min_fee` and `fee_rate` settings, 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 `fee_ratio`).

A wallet/node that uses your flooding algorithm – with, say, a minimum split size of 10k sats – could then heuristically ignore channels that:

1. Have any base fee
2. Have a `fee_ratio` that is greater than 10k sats, which should be incredibly rare

Most channels would probably have their `min_fee` set to 1 msat, simply to prevent 0-fee htlcs. In my 200 ppm example, the `fee_ratio` would be 5 sats.

In fact, just 1k sats is a magic number here! When the `min_fee` is 1 msat, then any channel with a nonzero `fee_rate` has a maximum `fee_ratio` of 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.

## 1 Answer

Note: Probably this should be a comment, but I don't have enough reputation, so I'll let it grow as an answer.

There is something I don't understand about this: why do you state that the fee function you propose is linear?

Let's say I set `10 msat/sat` feerate and `100 msat` min_fee. Payments from 1 msat all the way up to 10 sats would all pay a 100 msat fee. Only larger payments would start to pay more. This is not linear: it's constant up to some arbitrary amount and then it becomes linear increasing.

The `base_fee + feerate` model instead is really linear, starting off at `base_fee` for 0-amt payments and growing linearly from there.

So: your system is linear only in the special case where you set a really small min_fee, while the currently implemented system is always linear. If you want to solve the fact that small payments pay a too large fee, you can just set a lower base_fee (down to 1msat) and possibly a higher feerate. With such a settings the two systems are practically equivalent.

Now, I'm not familiar with Pickardt payments, so ther might be something there that would change everything.

TLDR: your system is practically linear only in case of very low min_fee and in this case it very much looks like the current system with low base_fee.

• `f(x) = ax +b` is the current fee model. For a function to be linear it is not sufficient that the plot looks like a straight line but rather the following equation needs to hold `f(x+y) =f(x) + f(y)` now it is easy to see that `f(x+y) + b = f(x) + f(y)` which only implies linearity if and only if `b=0`. That being said the proposed function with the max is also not linear and also at f(0) not even convex Aug 26, 2021 at 10:39
• Oh, you need the precise notion of linearity. But then you need to have that `f(0)=0` and as far as I understood we don't want to have free 0-amt payments. Looks like there's no clear way out then...
– St3p
Aug 26, 2021 at 13:42
• of course `f(0)=0` is necessary as we don't want to pay channels if we don't send something over them. but maybe I miss your point here. anyway your answer lead me to also write a much longer post on the mailinglist so I drop that here for reference: lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/… Aug 26, 2021 at 14:57