Spam detection by pattern recognition

I have an idea on how to limit the impact on spam attacks. This idea may be flawed so I hope some of you clever guys could help me brainstorm this idea and point out any problems.

If I want to spam the network I would spin up a node and then calculate pow for thousands of transaction and then publish all them through my node as fast as possible.
Looking at my nodes blockpublishing history it is clearly visible to us that this was spam and not organic transactions. There will be a short big spike in transactions and then back to zero.

Nodes that publishes organic transactions (like an exchange) will usually have a long history of publishing blocks at a somewhat steady rate.
My idea is to extend node monitoring to record the average daily publishing bps for nodes and then use this to estimate if a node is following it's normal pattern (within an allowed tolerance)
Nodes that suddenly breaks their normal publishing pattern (say 10x transactions) would have their max publishing rate throttled to their average bps rate

A spammer would no longer be able to precalculate the spam. He needs a high daily average transaction rate to be able to send at an even higher rate.

I'm sure there is something obvious that I'm missing here because it seem like a very simple solution that is easy to implement.

One problem that I see is that if a service is down for a few days it will come back online to an average daily transaction rate of zero. Using weekly or monthly average rates could be used to combat this.

1 Like

What stops a spammer from spinning up lots of nodes and using them within the limits?
You already pointed out potential trouble for legitimate users. At the same time it can't really help against spam.
All it does is making it a little bit more complicated for the spammer when they attempt to spam and always for other users.
That doesn't sound like a trade I'd want to make.

New nodes will also have a daily average transaction rate of zero so they will be throttled too.
So a spammer can't precompute a spam attack, only do real time spamming.

Not really. If a service is down for several days it will just take a one day until it's no longer throttled.

Btw, a throttled node does not mean that it is crippled. Maybe just throttled to max 10 bps. This is more than enough for any of the current services. But it will make it impossible for a spammer to create 1000 bps spam like they do now.
New nodes with no history should not be able to send out 1000 bps

From a practical standpoint, how do you see us associating a transaction with an origination node? It seems like this would have to be signed into the block, otherwise the origin can be forged. There would also need to be a way to agree with that node that you're authorized to consume their tx budget, otherwise it would be a denial of service vector.

I guess my knowledge on how the voting mechanism works is not good enough to answer this.

I was under the impression that nodes could just throttle blocks from nodes that had no recent history of high transactions count. If I understand your answer correctly, it is possible for a node to pretend that it is another node?

I'm in over my head here on the technical part. At the conceptual level this all hinge on knowing the identity of the publishing node and its average daily publishing history

Ahh yea, part of what the network does is "gossip", tell others about transactions/votes that it's heard about. This gossip would make it look like another node is sending the transaction but it's not the originator.

1 Like