<div dir="ltr"><div><div>Hi ZmnSCPxj,<br><br></div>As of today, you can setup a `htlc_minimum_msat` higher than remote's `dust_limit_satoshis`, but you don't necessarily know it before announcing your channel parameters if you're initiator.</div><div>In practice, assuming you can do so, with fees going higher and HTLC outputs being encumbered, their cost-to-spend will increase so forbidding dust HTLC will outlaw low-value payments, which them are a constant.<br><br>> Adding this to the spec does have the advantage that an honest forwarder
 can hold an HTLC for a while once it notices that the next hop has a 
bunch of dusty HTLCs in-flight that are beyond the negotiated 
`max_dust_htlc_value_in_flight_msat`, which might help reliability of micropayments slightly, but there is still the reduction of reliability.</div><div><br></div><div>I agree you can already fail HTLC as a local forwarding policy, which is not great for reliability. So you may have either a negotiated `max_dust_htlc_value_in_flight_msat` or refuse an `open_channel`/`accept_channel` by receiver considering remote's  `dust_limit_satoshi` too high. <br><br></div><div>I do think that's a pretty low-risk scenario but that would be better if implementations somehow bound in-flight dust to lower attack incentive.<br><br></div><div>Antoine<br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 18 mai 2020 à 20:52, ZmnSCPxj <<a href="mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Antoine,<br>
<br>
<br>
> Mitigating may come by negotiating a new `max_dust_htlc_value_in_flight_msat` enforced by HTLC recipient, therefore expressing its maximum trust tolerance with regards to dust. Bearing a cost on a HTLC holder will also render the attack more expensive, even if for counter-measure efficiency you likely need a different order of magnitude that spam-protection.<br>
<br>
Even without a spec change, such a setting may be enforced by a forwarding node by the simple act of refusing to forward an HTLC once a certain level of incoming dust HTLCs are currently in-flight.<br>
That is, the forwarding node can simply accept the incoming new dusty HTLC, but instead of forwarding, claim a `temporary_channel_failure` on the next channel.<br>
The attack requires that the forwarding node actually forward the HTLC, after all.<br>
<br>
This will of course lead to reduced reliability on micropayments.<br>
<br>
Adding this to the spec does have the advantage that an honest forwarder can hold an HTLC for a while once it notices that the next hop has a bunch of dusty HTLCs in-flight that are beyond the negotiated `max_dust_htlc_value_in_flight_msat`, which might help reliability of micropayments slightly, but there is still the reduction of reliability.<br>
Not to mention that the easiest code change to respect such a limit would be simply to fail forwarding anyway.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>