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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
