Published on: 2020-05-20T03:26:54+00:00
In a recent message exchange, the discussion revolves around the issue of preventing irrevocable removal of HTLCs in the incoming channel. ZmnSCPxj suggests that state machine shenanigans are not effective in addressing this problem, as the miner can recover funds by closing the outgoing channel. One proposed solution is to set up the `htlc_minimum_msat` higher than the remote's `dust_limit_satoshis`. However, this approach has drawbacks as it prohibits low-value payments and reduces reliability.The conversation explores the idea that an honest forwarder may hold an HTLC for a while if the next hop has a large number of dusty HTLCs beyond the negotiated `max_dust_htlc_value_in_flight_msat`. This could potentially improve micropayment reliability to some extent. It is suggested that adding a limit to the specification could be beneficial in this regard. Nevertheless, even with negotiation, the reliability of micropayments remains reduced due to the possibility of easily saturating the micropayment bandwidth.Another aspect of the discussion focuses on negotiating a new `max_dust_htlc_value_in_flight_msat` enforced by the HTLC recipient. This would express the recipient's maximum trust tolerance concerning dust and help mitigate attacks. However, it is noted that implementing such a change would lead to reduced reliability for micropayments. Additionally, enforcing this setting by a forwarding node, even without a spec change, can be achieved by refusing to forward an HTLC once a certain level of incoming dust HTLCs is in-flight.The message also highlights the potential mitigation of an attack on the Lightning Network. The suggested solution involves negotiating a new `max_dust_htlc_value_in_flight_msat` enforced by the HTLC recipient to express their maximum trust tolerance for dust. This would increase the cost for the attacker and make the attack more expensive. However, the order of magnitude for cost increase may need to be adjusted for spam-protection efficiency. Implementing this mitigation, either through a spec change or by the forwarding node's refusal to forward HTLCs with excessive dust, would provide some improvement in micropayment reliability.The Lightning protocol allows for a floating dust output selection at channel creation, where each party declares a dust parameter applicable to their local transactions. The current specification does not impose any bound on this value, except that it must be lower than the `channel_reserve_satoshis`. When an HTLC is routed through the channel but its value falls below the local party's dust limit, it is burned as fees and not added to the commitment transaction. While this makes the Lightning Network compliant with Bitcoin blockchain requirements, it also introduces a higher level of trust in the counterparty.The conversation presents an attack scenario where Mallory sets a channel with a dust limit significantly lower than the channel's value. By routing multiple dust-HTLCs through Alice, Mallory can claim a large portion of the channel's value with the collusion of Mallet. Mallory then broadcasts a commitment transaction without any HTLCs, rendering them unclaimable by Alice on-chain. This attack may seem economically irrational at first, considering the dust-HTLCs are committed as fees. However, if Mallory can collude with a mining pool, the economics change as fees go back to the miner. By keeping the commitment transaction in the miner pool until a block is found, the attack can remain hidden, especially if the block is not signed.To mitigate this type of attack, negotiating a new `max_dust_htlc_value_in_flight_msat` enforced by the HTLC recipient is suggested. This would express the maximum trust tolerance for dust and enhance security against such attacks.
Updated on: 2023-07-31T22:56:07.840590+00:00