😄

The problem with me filtering stuff is I’m not sure what I don’t see anymore, but the network does. ha.

I do have an event rejection queue, but it’s limited in size.

I hate spending the time on it, spam is just wasting my time, but I’ve built some pretty solid detection across the board. Have a few more things in the works.

Literally just purged another 800k events from my db, by backtesting against new defences.

Reply to this note

Please Login to reply.

Discussion

It is really hard for relay operator, especially for free public relay operator. They will eventually have to face this kind of DoS spam attack which seems to target their performance (bloating database). Even for you as relay operator + data scientists , need a lot of work and patience. 😅

Great works for all you've done

Yeah. It’s why I’ve built that PoW Service Provider. I’ll open source it this week. It’s not complete 100%, but good enough perhaps to whitelist pubkeys and test it.

It’s funny, I’ve mostly been messing with aggregation and spam stuff to help find performance weaknesses and address them - before the network 10x and then 10x again. I think 1000x, and we likely start seeing the network become islands, and relays become tiered into classes.

Oh, so it is like Delegated PoW service. Any suspicious users can be redirected to your service to do PoW to make them whitelisted on certain relays?

Same, we can probably see it in near future. Especially when adoption of new users increase rapidly. Honestly, client with gossip model discovery like https://github.com/mikedilger/gossip + fully implementarion of NIP-65 will alleviate some burden of relays