Good morning Antoine,
> 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. 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. 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. The attack requires that the forwarding node actually forward the HTLC, after all. This will of course lead to reduced reliability on micropayments. 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. Not to mention that the easiest code change to respect such a limit would be simply to fail forwarding anyway. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
