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.

LDK v0.1.1: Duplicate HTLC Force Closing Griefing Vulnerability Fix
  • 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 to ChannelManager::send_payment (rather than like the pre-0.1 send_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::SpendableOutputs could have caused
    OutputSweeper 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 invalid Route,
    provided to ChannelManager, can result in an outbound payment remaining pending forever despite no HTLCs being pending.

GitHub Repo
Vulnerability Disclosure / Archive