<p><em>Note: Probably this should be a comment, but I don't have enough reputation, so I'll let it grow as an answer.</em></p>
<p>There is something I don't understand about this: why do you state that the fee function you propose is linear?</p>
<p>Let's say I set <code>10 msat/sat</code> feerate and <code>100 msat</code> 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.</p>
<p>The <code>base_fee + feerate</code> model instead is really linear, starting off at <code>base_fee</code> for 0-amt payments and growing linearly from there.</p>
<p>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.</p>
<p>Now, I'm not familiar with Pickardt payments, so ther might be something there that would change everything.</p>
<p><strong>TLDR:</strong> 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.</p>

CC BY-SA 4.0
2021-08-26T10:39:44.443Z
`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
Rene Pickhardt
CC BY-SA 4.0
2021-08-26T13:42:42.400Z
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
CC BY-SA 4.0
2021-08-26T14:57:55.857Z
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: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003203.html
Rene Pickhardt
CC BY-SA 4.0
2021-08-26T09:50:09.940Z
2021-08-26T09:50:09.940Z
St3p
<h2>What is a <code>min_fee</code>?</h2>
<p>Having a <code>min_fee</code> means changing the fee calculation to <code>max(min_fee, fee_rate * amt)</code>, potentially replacing the <code>base_fee</code>. My reasoning behind this is that it prevents 0-fee payments – fees below 1 msat are currently rounded down to 0 – without setting a <code>min_htlc_msat</code> or <code>base_fee</code>.</p>
<h2>How does it help?</h2>
<p>Not setting a <code>min_htlc_msat</code> makes sure that micropayments can still be routed, while not setting a <code>base_fee</code> ensures a linear fee function for <a href="https://arxiv.org/abs/2107.05322" rel="nofollow noreferrer">Pickhardt payments</a>.<br />
While my proposed fee function is generally <em>not</em> linear, it can be ensured that it always <em>is</em> linear in practice. I showed this in a <a href="https://www.reddit.com/r/TheLightningNetwork/comments/p239as/rounding_up_fees_min_fee/h8ieqeu?utm_source=share&amp;utm_medium=web2x&amp;context=3" rel="nofollow noreferrer">reddit thread</a>, responding to Rene Pickhardt. Here's my response in full, if you don't want to go to that reddit thread:</p>
<blockquote>
<p>My idea behind <code>max(min_fee, fee_rate * amt)</code> was the fact that for reasonable <code>min_fee</code> and <code>fee_rate</code> settings, the function is linear even for relatively small payments.</p>
<p>More exactly, the function is linear for <code>fee_rate * amt &gt;= min_fee</code> – or equivalently <code>amt &gt;= min_fee / fee_rate</code> (let's call this the <code>fee_ratio</code>).</p>
<p>A wallet/node that uses your flooding algorithm – with, say, a minimum split size of 10k sats – could then heuristically ignore channels that:</p>
<ol>
<li>Have any base fee</li>
<li>Have a <code>fee_ratio</code> that is greater than 10k sats, which should be incredibly rare</li>
</ol>
<p>Most channels would probably have their <code>min_fee</code> set to 1 msat, simply to prevent 0-fee htlcs. In my 200 ppm example, the <code>fee_ratio</code> would be 5 sats.</p>
<p>In fact, just 1k sats is a magic number here! When the <code>min_fee</code> is 1 msat, then any channel with a nonzero <code>fee_rate</code> has a maximum <code>fee_ratio</code> of 1k sats (<code>0.001 / 0.000001 = 1000</code>)!</p>
<p>So even all the way down to 1k sat payment splits, any channel with a 1 msat <code>min_fee</code> – and a nonzero <code>fee_rate</code> – has a linear fee function.</p>
</blockquote>
<h2>Is it a good idea?</h2>
<p>Now I would like to know if there are any fundamental issues here that I'm missing.<br />
It seems to me that it could serve as a replacement for the (iirc arbitrary) <code>base_fee</code> setting, while still allowing Pickhardt payments.</p>

<lightning-network><lightning-routing>
Would a min_fee setting for Lightning channels make sense?
Fitti
# Would a min_fee setting for Lightning channels make sense?

(Asked by: username_0 on 2021-08-11)

## 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](https://arxiv.org/abs/2107.05322).  
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](https://www.reddit.com/r/TheLightningNetwork/comments/p239as/rounding_up_fees_min_fee/h8ieqeu?utm_source=share&utm_medium=web2x&context=3), responding to username_2. 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.

**Tags:** lightning-network, lightning-routing


---

## 1 answers

### Answer by username_1 on 2021-08-26. Score: 2

*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.

> **Comments:**
> **username_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  
> **username_1**: 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...  
> **username_2**: 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: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003203.html  

---

