<blockquote>
<p>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;.</p>
<p><strong>Local spam</strong> is someone sending or requesting too much data: that's a simple batter of code with rate limiting etc.</p>
<p><strong>Fast spam</strong> 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 <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002275.html" rel="nofollow noreferrer">here</a>.</p>
<p><strong>Slow spam</strong> 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 <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html" rel="nofollow noreferrer">proof-of-channel closure</a> 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.</p>
<p>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.</p>
</blockquote>
<p>This question was answered by Rusty Russell on <a href="https://twitter.com/rusty_twit/status/1308566351556964354?s=20" rel="nofollow noreferrer">Twitter</a>.</p>

CC BY-SA 4.0
2020-09-23T16:08:53.637Z
Hi Michael, love the content you have been putting up here lately. Please be sure to format quotes as such when you copy them. Stuff like "solution I like" become a bit confusing when it's not clear that the whole answer is a quote.
Murch
CC BY-SA 4.0
2020-09-23T16:13:05.723Z
Sure. Will do. Thanks for the feedback!
Michael Folkson
CC BY-SA 4.0
2020-09-23T08:57:16.537Z
2020-09-23T16:07:31.210Z
2020-09-23T16:07:31.210Z
Michael Folkson
<p>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?</p>

CC BY-SA 4.0
2020-09-23T16:22:08.330Z
I've unquoted this as this isn't a quote. It is just me writing what question Rusty is answering.
Michael Folkson
<lightning-network><core-lightning><spam>
What are the different types of spam that the Lightning Network is subject to?
Michael Folkson
# What are the different types of spam that the Lightning Network is subject to?

(Asked by: username_0 on 2020-09-23)

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?

**Tags:** lightning-network, core-lightning, spam

> **Comments:**
> **username_0**: I've unquoted this as this isn't a quote. It is just me writing what question Rusty is answering.  

---

## 1 answers

### Answer by username_0 on 2020-09-23. Score: 3

> There are three types of spam problem in the Lightning Network. Let's
> call them "local","fast" and "slow".
>
> **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](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002275.html).
>
> **Slow spam** is sending a long-lived payment. This consumes capacity > 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](https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html) 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](https://twitter.com/rusty_twit/status/1308566351556964354?s=20).

> **Comments:**
> **username_1**: Hi Michael, love the content you have been putting up here lately. Please be sure to format quotes as such when you copy them. Stuff like "solution I like" become a bit confusing when it's not clear that the whole answer is a quote.  
> **username_0**: Sure. Will do. Thanks for the feedback!  

---

