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

[ZmnSCPxj]

Good morning Antoine,

As well, I considered doing state machine shenanigans for this (do not sign for removal of HTLC in your outgoing channel until you have irrevocable removal of HTLC in your incoming channel) but this does not work since if you already have a miner willing to cooperate with you and which you can plausibly believe will share the amount with you, the miner can recover the funds by simply closing the outgoing channel as well.


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

Even if such a limit is negotiated it seems reliability is still reduced --- if the limit is too low in practice then it would be easy for the micropayment bandwidth to be saturated anyway and such tiny payments will not push through.
It is still slightly better though.

Regards,
ZmnSCPxj