Fee-Based Spam Prevention For Lightning

Posted by harding

Mar 18, 2025/15:11 UTC

The proposal in question fails to address a significant criticism previously highlighted, concerning the handling and implications of held HTLCs (Hash Time-Locked Contracts) within the Lightning Network's operational framework. A central issue is the absence of a universal clock or a reliable method to prove message delivery and acknowledgment, leading to potential exploitation where a node could be coerced into incurring unwarranted hold fees. This situation arises when an HTLC is not promptly resolved—either accepted or rejected—forcing the initiating node to consider force-closing the channel to mitigate further financial losses. The scenario described showcases a manipulative strategy where one party, referred to as Bob, forwards an HTLC to another party, Mallory, who then deliberately abstains from responding. Consequently, Bob faces a dilemma: either incur ongoing hold fees charged by his upstream node, potentially controlled by Mallory, or opt for an onchain transaction to force-close the channel, thereby incurring additional fees without guaranteeing a success fee.

In a more detailed example, the manipulation involves two nodes operated by Mallory (M0 and M1), with Bob's node caught in between. M0 transmits funds through Bob to M1, imposing on Bob a series of financial burdens: an initial upfront fee paid to M0, a hold fee exceeding the upfront fee, and the eventual onchain transaction fee necessary for force-closing the channel. This intricate scheme highlights the potential for substantial financial loss on Bob's part, juxtaposed against the relatively minimal expenses incurred by Mallory for orchestrating the attack, especially when considering the possible earnings from extended blocks of hold fees.

The discussion also touches upon the risks associated with hold fees in the context of JIT (Just-In-Time) channels, as outlined in an article available at BitcoinOps. In such cases, Mallory can exploit the system by forwarding payments through an LSP (Lightning Service Provider) to a non-existent customer, thereby obligating the LSP to cover the hold fees until a double spend of the channel opening transaction is executed and confirmed. This strategy emphasizes the minimal costs faced by Mallory in comparison to the potentially significant financial repercussions for the victimized parties involved in this exploitative cycle.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback