Author: Antoine Riard 2021-10-04 18:50:55
Published on: 2021-10-04T18:50:55+00:00
The Lightning Network, specifically the Eclair, LND, LDK, and c-lightning implementations, has been found to have vulnerabilities at the specification level that can be exploited in various attacks. Attackers can utilize the vulnerabilities to blackmail node operators for fees, burn liquidity of competing LSPs, or even steal the counterparty channel balance. One vulnerability allows Alice to inflate the dust limit until reaching the implementation-defined max value, resulting in substantial loss to Bob's funds by publishing her commitment on-chain. Another vulnerability can be exploited through in-flight outgoing HTLC committed as fees on Bob's commitment if they're under Bob's threshold. To mitigate these vulnerabilities, the proposal introduces a new configurable limit called `max_dust_htlc_exposure`, which should be applied to incoming and outgoing HTLCs. To achieve this goal, a new `dust_buffer_feerate` is defined as the maximum of either 2530 sats per kWU or 125% of the current `feerate_per_kw`. Upon an incoming HTLC, if the HTLC's `amount_msat` is less than the counterparty's `dust_limit_satoshis` plus the HTLC-timeout fee at the `dust_buffer_feerate`, and if the `amount_msat` plus the `dust_balance_on_counterparty_tx` is greater than `max_dust_htlc_exposure`, the HTLC should be failed once it's committed. Similarly, upon an outgoing HTLC, if the HTLC's `amount_msat` is less than the counterparty's `dust_limit_satoshis` plus the HTLC-success fee at the `dust_buffer_feerate`, and if the `amount_msat` plus the `dust_balance_on_counterparty_tx` is greater than `max_dust_htlc_exposure`, the HTLC should not be sent and fail without forwarding. A last mitigation is ensuring that at `update_fee` reception, the pending `dust_balance` at the new proposed feerate isn't greater than `max_dust_htlc_exposure_msat`. The proposal requires node operators to fine-tune the value in function of what qualifies as an acceptable loss.The Lightning Network has suffered from vulnerabilities around dust HTLC processing for years. Although the specification did not require that the `open_channel`/`accept_channel` receiver verifies that the announced `dust_limit_satoshis` isn't too large or that the sum of the dust HTLC committed as fees was verified against an upper bound, developers from three different implementations actively participated in diagnosing the vulnerabilities and developing mitigations. In May 2020, a high-level attack scenario titled "Miners Dust Inflation attacks on Lightning Network" was published, leveraging the lack of a check on counterparty's dust limit. Mitigations were developed and released on the LDK-side after a successful test of the first vulnerability against LND software in February 2021. In July 2021, discussions followed on the best way to mitigate a new vector reported by Eugene Spiegel (LND) on how to exploit the trimmed-to-dust mechanism at `update_fee` reception. Mitigations were developed and released on the LDK-side during August 2021, and vulnerabilities were disclosed to other Lightning projects such as Muun wallet and Electrum. A public disclosure date was proposed from the LDK-side. During this time, the Bitcoin Core dust limit was also actively discussed on the mailing list. On October 4th, 2021, full disclosure of CVEs was made, and BOLT PR #919 was submitted covering the remaining vulnerabilities. The dust limit is a base layer policy stopping the relay of a transaction if one of its outputs is below a specified threshold. Lightning commitment transactions with one of its outputs below the dust limit would fail to relay and thus jeopardize funds' safety.
Updated on: 2023-06-03T06:08:06.447376+00:00