From antoine.riard at gmail.com Mon May 18 10:28:21 2020 From: antoine.riard at gmail.com (Antoine Riard) Date: Mon, 18 May 2020 06:28:21 -0400 Subject: [Lightning-dev] Miners Dust Inflation attacks on Lightning Network Message-ID: Lightning protocol supports a floating dust output selection at channel creation, where each party declares a dust parameter applying to its local transactions. The current spec doesn't enforce or recommend any bound on this value, beyond the requirement of being lower that `channel_reserve_satoshis`. When a HTLC is routed through the channel but its value is under the local party dust limit, it's burned as fees and not added to the commitment transaction. This rule, which makes LN a good citizen of the Bitcoin blockchain comes at the price of more trust in your counterparty.. Let's consider the following scenario. Mallory announces a channel to Alice with dust-limit-satoshi set to 20% of channel value. Alice should accept incoming channels as long as its under her implementation-specific `max_dust_limit_satoshis`. Now Mallory can route 4 dust-HTLCs to Mallet through Alice claiming ~80% of channel value. Mallory --> Alice --> Mallet Mallet, in collusion with Mallory, can claim the whole set of HTLCs by revealing the corresponding preimage for each. At the exact same time, Mallory broadcast her latest commitment transaction on which there is _no_ HTLCs because all of them are dust. Alice can't claim them onchain but has already paid Mallet forward. At first-look, this attack doesn't seem economically rational because dust-HTLCs are all committed as fees. But if you assume that Mallory can collude with some mining pool, economics change completely because it's now a almost zero-cost to add Mallory commitment transaction in a block, hashrate won't be wasted. Fees are going back to the miner, and Alice is still robbed. Mallory commitment transaction may stay in miner pool as long block isn't found, without being announced to the rest of the network, and HTLCs timelocks don't expire. Attack may still stealth if block isn't signed. It's almost a zero-cost because if you assume block being full, commitment transaction is now competing for block space and there is an opportunity cost. It's that kind of low-probability-and-hard-to-exploit-vulnerability but you would prefer not having to think about your big LSP hub being targeted by a rogue mining pool employee. Even if it's a really small mining pool, you may batch the attack on multiple channels at once for one block found. Deployment of Stratum V2 may make the attack easier by giving more leverage to the local miner. Mitigating may come by negotiating a new `max_dust_htlc_value_in_flight_msat` enforced by HTLC recipient, therefore expressing its maximum trust tolerance with regards to dust. Bearing a cost on a HTLC holder will also render the attack more expensive, even if for counter-measure efficiency you likely need a different order of magnitude that spam-protection. Cheers, Antoine -------------- next part -------------- An HTML attachment was scrubbed... URL: