EggPool
commented
4 years ago @n-y-z-o My best candidate version so far, with the most minimal changes I was able to introduce to fight back the queue spam, is 595002: https://github.com/Open-Nyzo/nyzoVerifier and changelog at https://github.com/Open-Nyzo/nyzoVerifier/blob/master/changelog.md
I'll merge 596 and issue a PR here once I have more feedback on this version. The 595001 version already drastically reduced the number or always red in queue nodes, mostly from networks of 256 c-class ips.
Ref:
A huge part of the queue is composed of "red" verifiers.
With current working, a new IP only has to answer once to a nodejoin so it is added to the "nodes" file, then all it has to do is send nodejoins from its IP to reset the "failed" counter.
That "failed" counter is only incremented on a failed answer. It is reset on a successful answer (good), but also on any nodejoin incoming message.
Big players with large IP blocks exploit that to drastically reduce costs and keep their IPs alive just by spamming nodejoins to the cycle every few hours once they are in the "nodes" file to maintain their rank.
Proposal 1: Do not reset the failed counter on incoming nodejoin message, just on a successful answer.
Maybe slightly raise the threshold to avoid side effects, like DDoS being too effective.
Proposal 2: (Thanks to Dkat) Faking a nodejoin or nodejoin answer is way too easy and can be done with a few lines of code, not needing a real verifier, not needing chain data.
To be valid, a nodejoin answer could require a simple challenge, for instance: