LDK v0.1.1: Duplicate HTLC Force Closing Griefing Vulnerability Fix
LDK/rust-lightning is a highly performant and flexible implementation of the Lightning Network protocol. LDK v0.1 and earlier are vulnerable to a griefing attack that causes all of the victim’s channels to be force closed. Update to LDK v0.1.1 to protect your channels.
- Lightning Dev Kit v0.1.1 fixes a denial-of-service vulnerability allowing channel counter-parties to cause force-closure of unrelated channels.
- This vulnerability was discovered during an audit of LDK’s chain module by Bitcoin developer and security researcher Matt Morehouse, who named it 'Duplicate HTLC Force Close Griefing.'
"The attacker must broadcast a revoked commitment transaction, thereby forfeiting their channel balance. But the size of the channel can be minimal, and the attacker can spend their balance down to the 1% reserve before executing the attack. As a result, the cost of the attack can be negligible compared to the damage caused," said the developer.
- From version 0.1.1, LDK proactively fails HTLCs nearing their deadlines if the downstream channel is or is being force-closed. This prevents cascading force closures during fee spikes and ensures duplicate HTLCs are failed back after a revoked transaction confirms, avoiding upstream channel force closures.
What's new in LDK v0.1.1
- API Updates: A
ChannelManager::send_payment_with_route
was (re-)added, with semantics similar toChannelManager::send_payment
(rather than like the pre-0.1send_payent_with_route
, #3534).RawBolt11Invoice::{to,from}_raw
were added (#3549).
- Duplicate HTLC Force Close Griefing fix for a denial-of-service vulnerability allowing channel counterparties to cause force-closure of unrelated channels.
Bug fixes
- If an inbound HTLC is set to expire within the next three blocks, it will be failed backward regardless of the outbound HTLC's status. This prevents peers from force-closing channels to claim the inbound HTLC on-chain, even if the outbound HTLC hasn't been claimed on-chain yet.
- On restart, replay of
Event::SpendableOutput
s could have causedOutputSweeper
to generate double-spending transactions, making it unable to claim any delayed claims. - Fixed the additional feerate we will pay each time we RBF on-chain claims to match the Bitcoin Core policy (1 sat/vB) instead of 16 sats/vB.
- Fixed a cased where a custom
Router
which returns an invalidRoute
,
provided toChannelManager
, can result in an outbound payment remaining pending forever despite no HTLCs being pending.
GitHub Repo
Vulnerability Disclosure / Archive
- Do you want more? Subscribe and get No Bullshit GM report straight to your mailbox and No Bullshit Bitcoin on Nostr.
- Feedback or news tips? Drop it here.