OP! This isn't cool. @oefrha basically did a free security audit for you and instead of being grateful for that, you get defensive and flag them? How is this cool?
I also had the same question as tromp about how you're validating that clients aren't cheating. @oefrha's analysis shows you aren't validating. How can we be 100% sure that none of the clients cheated? What if there is a counterexample to the conjecture but one of your clients didn't report it because they cheated? Math results require rigor and without rigor the bold claim is only a "claim" right now, not a fact!
*I had to look up that word
---
This is basically a free security audit, even though I only spent like five minutes. If your application can be "hacked" so easily, it's very irresponsible to say you're "verifying" the conjecture. Removing the comment doesn't make your application any more secure.
Btw, I even helpfully pointed to prior art which you can learn from. A butthurt response is pretty sad.
I hope this comment answers to your question.
I will continue my project to seek meaningful purpose in some extent.
That's not what's happening here. People in this thread are simply asking in good faith how the server-side verifies the results submitted by the client. It’s a fair question. And an important one. In fact, it might be the most important question when making such a bold claim.
If this isn't addressed, there's no way to know that a client didn't cheat by withholding a valid counterexample. And if even one client cheats, the entire claim made in this 'Show HN' thread falls apart.
You both are agreeing with each other.
To request a new batch:
returns something like which means the client should check 4000075534400000000-4000075534500000000.Once done:
Here, _client_hash is generated by wasmHash(`{"method":"Hash"}`) in /js/worker.js (yes, the payload is a fixed string), and while I didn't try to disassemble the wasm, one can pause execution and repeatedly call wasmHash() to observe it's basically a TOTP that changes every 10s, so it doesn't carry any mathematical information.Therefore, all the info that can be used for verification on the server is a single pair of _p and _q adding up to one number in the entire range. That's the extent of the verification.
One can of course patch the code to check a single number before reporting that the entire range has been checked. Pretty sure it's impossible for the server to detect that.
Correct me if I made a mistake somewhere.
Edit: On second thought, maybe the specific number reported back is deterministically chosen in a way that relies on finishing all the checks in the range, and thus can be compared with other reported results for the same range?
Even in that case, the server can't verify the work without repeating it. mersenne.org hands out a double checking job about 8 years later presumably to thwart determined attackers.[1]
[1] https://www.mersenne.org/various/math.php