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.


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.

  • 2
    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 at 10:39
  • 2
    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 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 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.