Relay amounts lower than min_htlc if fee is high enough

[thomash-acinq]

There is no reason to reject HTLCs with amounts below htlc_minimum_msat if the fees are high enough to pay for htlc_minimum_msat.

[TheBlueMatt]

I disagree, one of the things htlc_minimum let's you do is avoid having dust or <1sat amounts, both of which are reasonable desires.

[thomash-acinq]

A motivation for this proposal is the rise of zero base fees. With zero base fees we need a higher htlc_minimum_msat to prevent excessive splitting of the payments to reduce fees (because proportional fees are currently rounded down) but there is no reason to let this prevent us from continuing to relay small HTLCs. Another solution that would solve that is to round proportional fees up.

[t-bast]

I'm not sure we want this change, htlc_minimum_msat can also be used to ensure htlcs below a given value are rejected because we don't want them using up one of our previous 483 slots in the commit tx, which is a concern that's completely unrelated to fees but rather a security policy

[thomash-acinq]

@TheBlueMatt @t-bast These are valid concerns, we shouldn't drop htlc_minimum_msat. It's just that since zero base fees seem to be gaining traction (the rate cards discussion last week seemed to go in that direction), we need to think about an obvious attack that would allow anyone to not pay any fees: just split the payment to parts that are small enough to not pay any fee (or a significantly lower fee than without a split).

[t-bast]

I understand that concern and it makes sense, but shouldn't the node operator just raise their htlc_minimum_msat value or their proportional fee in that case, so that the fee is always > 0 if that's what they want? With an htlc_minimum_msat of 1 sat and a proportional fee of at least 1/1000 you guarantee that there's always going to be at least a 1 msat fee paid

[thomash-acinq]

With an htlc_minimum_msat of 1 sat and a proportional fee of at least 1/1000 you guarantee that there's always going to be at least a 1 msat fee paid

With these settings, I'm incentivized to split my payments in 1999 msat parts to pay half the fees.

[t-bast]

That's true, but whenever we implement the htlc amount bucketing strategy we discussed in Zurich (it's on my todo-list!) it will break this incentive. If I only allow 25% of my commit tx slots to be used for htlcs below a given value, splitting payments too aggressively will negatively hurt reliability, so the aggressive splitting isn't the best strategy for payers.

We can also simply specify that once we move to scorecards that don't contain a base fee, fees must be rounded up. I'm not sure yet how we'll handle the migration to scorecards, but that provides a path for deprecating the base fee without introducing incentives to split too aggressively.

[TheBlueMatt]

An alternative would be to not use 0 base fees :). I mean node operators are always going to do things because they want to give away their services for free, even if it makes them a DoS-magnet. I'm not sure there's much we can do for those operators.