Author: lisa neigut 2021-10-04 18:15:59
Published on: 2021-10-04T18:15:59+00:00
The Lightning Network is a popular payment protocol built on top of the Bitcoin blockchain, with implementations such as Eclair, LND, LDK, and c-lightning. However, these implementations have vulnerabilities that can lead to various attacks, including fee blackmailing of node operators, burning liquidity of competing Lightning Service Providers (LSPs), and stealing counterparty channel balance. These vulnerabilities arise because Alice's `dust_limit_satoshis` can be inflated until it reaches the implementation-defined max value, which allows her to inflict a substantial loss on Bob's funds by publishing her commitment on-chain. Moreover, in-flight incoming and outgoing HTLCs (Hashed Time-Locked Contracts) can also be committed as fees under the dust limit, leading to further loss of funds. To mitigate these vulnerabilities, several solutions have been proposed. Firstly, the counterparty's announced `dust_limit_satoshis` should be verified at channel opening reception and rejected if it's estimated too large. Secondly, a new configurable limit `max_dust_htlc_exposure` should be defined and applied at incoming and outgoing of HTLC. Additionally, a new `dust_buffer_feerate` should be introduced to prevent sudden exposure to significantly more trimmed balance if the feerate increases with several HTLCs pending near the dust limit. Lastly, at `update_fee` reception, the pending `dust_balance` at the new proposed feerate should not exceed `max_dust_htlc_exposure_msat`.The background of the vulnerabilities lies in the dust limit policy that prevents the relay of transactions if one of its outputs is under a given threshold. Lightning commitment transactions should be able to propagate unilaterally during the channel lifetime to enforce on-chain balance. However, a transaction with one of its outputs below the dust limit would fail to relay and jeopardize funds safety. Despite requiring counterparties to announce a `dust_limit_satoshis` during channel opening, the specification did not require the verification of the announced value or the sum of dust HTLC committed as fees against an upper bound.There have been long-standing issues with the dust HTLC processing in Lightning Network that were known by some developers and researchers. In Q1 2019, potential safety risks around dust HTLC processing were discussed privately on the Rust-Lightning-side. In November 2019, Rusty Russell opened an issue against the specification mentioning the lack of check of counterparty's dust limit. In May 2020, a high-level attack scenario was published leveraging this lack. In February 2021, a test of the first vulnerability against LND software was done, and mitigations started to be developed on the LDK-side. In July 2021, Eugene Spiegel reported on how to exploit the trimmed-to-dust mechanism at `update_fee` reception, and discussions followed on the best way to mitigate this new vector. Mitigations were developed and released on the LDK-side during August 2021. During this time, vulnerabilities were disclosed to other Lightning projects like Muun wallet and Electrum. The lack of well-defined communication process across Lightning teams was highlighted.Developers from three different implementations actively participated in the vulnerabilities diagnostic and mitigations development of those long-standing specification issues affecting the whole Lightning ecosystem. A timeline of events is provided, including the working exploit of the vulnerability against LND, the finding by Eugene Siegel, and the BOLT PR #894 covering the lack of verification of counterparty per-HTLC dust_limit_satoshis. The full disclosure of CVEs and BOLT PR #919 covering the remaining vulnerabilities were submitted on October 4, 2021.
Updated on: 2023-06-03T06:10:21.086742+00:00