You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 15, 2024. It is now read-only.
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:
latest known block, signed with in-queue verifier key (not tracking, maybe late, but not too much)
small pow challenge
probably limit answers to in-cycle nodes IP, with a quota to avoid DoS by requesting many challenges.
Requiring a more complex answer to nodejoin will make it harder to fake a real verifier, and will incite to run official code.
The text was updated successfully, but these errors were encountered:
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:
Requiring a more complex answer to nodejoin will make it harder to fake a real verifier, and will incite to run official code.
The text was updated successfully, but these errors were encountered: