[Lightning-dev] Miners Dust Inflation attacks on Lightning Network

[Antoine Riard]

Hi ZmnSCPxj,

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

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

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.

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.

Antoine

Le lun. 18 mai 2020 à 20:52, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200519/fb4e38c3/attachment.html>