user125003: 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:

Have any base fee
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.

user100784: 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.

125003: <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>
 100784: <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>
