What are the different types of spam that the Lightning Network is subject to? What are the different types of spam that the Lightning Network is subject to and what are the possible strategies for dealing with such spam?
There are three types of spam problem in the Lightning Network. Let's
call them &quot;local&quot;,&quot;fast&quot; and &quot;slow&quot;.
Local spam is someone sending or requesting too much data: that's a simple batter of code with rate limiting etc.
Fast spam is sending many failed payments.  You can't tell what will succeed and you can't blame the sending peer (they may not be the
source).  This attack is free since we only pay on success. The answer
is to require an up-front payment but it has to be small (making sure
your incentive is to succeed) and it should not leak information on
where you are in the path.  I've been unable to find a scheme I'm
happy with though, see my latest attempt here.
Slow spam is sending a long-lived payment. This consumes capacity &gt; 1000x expected for a normal payment and is similarly free (if you fail). The only solution I like here is to penalize slow payments by
requiring proof-of-channel closure but you can't always tell if
the payment was really in the channel and what if the close
transaction pays super-low fees / conflicts?  You need a Merkle tree
of claimed HTLCs, plus onion unwrapping, agreement on valid closes,
handling of fake Merkle trees... all possible but real work.
Summary: We can mitigate some attacks but real fixes need spec
improvements and implementation.  More attention from Smarter People
Than Me (hi!) will help us here.

This question was answered by Rusty Russell on Twitter.