And now for some TF results...

[LaurV]

Email verification should work (well.. at least, as you said, slow down some badass kids).
Limiting the number of results reported per day for new users should work too, or limbo them for few days, they will get discouraged seeing that their last bravado does not pop them immediately in top of the list.
Adding some CRC to the reported results would be the proper way to go.
Proof of work, anybody? Forcing an about 1 minute SHA calculus, or so...
Sure, all of these were discussed in the past, and they have advantages and disadvantages. There is no "perfect" or "foolproof" method. Fools are intelligent guys..
But small steps, day by day, and we will improve...


Edit: on the other hand, all these are easy to spot an kill. Reporting results in other's names would be more dangerous, for example, imagine me reporting fake TF results for Oliver to discredit him... They would be difficult to spot, due to his high activity, and later create a lot of headache to re-check his (enormous amount of) work, when people will start to find missing factors in his reported results. Right now, nothing stop me to do so. We used to "trade credit" in the past, for example I was CPU-bottlenecked but had a lot of GPU power available, and I was doing and reporting TF work for other people who did and reported CPU work (DC) for myself, and there was nothing to stop us. I don't believe things changed ever since. That's why I said the CRC is the proper way to go...

[ATH]

Limit how much credit a brand new account can turn in? Like max 1,000 GHz-days in the first week? or 10,000 GHz-days the first month? or whatever seems fitting.
Maybe 1000*x GHz-days where x is the age of the account in days.

Could you add the rule: If 2000 or more trial factor lines are reported without a single found factor it will alert you?

[ramgeis]

I would definitely use the expected success rate to detect possible bogus results.
When a user reports hundreds of thousands of GHz-days of work the actual success rate should converge to the expected one. A too big difference then triggers an alert.

[James Heinrich]

Originally Posted by LaurV

Adding some CRC to the reported results would be the proper way to go.

mfaktc v0.22-pre6 has some code for generating a checksum for each result line. The manual results form will validate the checksum for any results submitted with it, but obviously can't reject results without a checksum since it's not (yet) in common use.

Originally Posted by ATH

Could you add the rule: If 2000 or more trial factor lines are reported without a single found factor it will alert you?

There is now a similar rule in place, thanks for the suggestion. And I've fixed the SPE-typo that prevented my false-results alert system from working that should have flagged these results.

[Madpoo]

Originally Posted by LaurV

...
Adding some CRC to the reported results would be the proper way to go.
Proof of work, anybody? Forcing an about 1 minute SHA calculus, or so...

If it were asymmetrical so the server could quickly verify, that'd be okay. One glitch is that there are users who genuinely submit a LOT of results daily (think TJAOI or even the Gpu72 bot) so it might place an undue burden on them.

At least for official Prime95 clients, there's a security check in the result, but for other clients like mfakt* or gpuOwl, there's nothing like that.

We've actually been chatting with Ernst about getting mlucas to be able to use the API (hope I'm not spoiling any secret there...and it may or may not happen), but part of that is that API usage for the most part is restricted to "secure" clients that send a valid security hash in the requests.

We can set Ernst up with his own key so the client/server can trust each other, but the problem comes in because of the need to be open source. I guess it could be like Prime95 where the security bits are not made public and you can build without it, with the net effect being it cripples the automatic communication. Or something like that... I vaguely recall that it adds "UNTRUSTED" to the result or some such.

And besides the API security, it'd be nice to have those other apps be able to include a hash in the result line itself even for manual results.

Maybe it wouldn't be too terrible to let the official builds have the security features intact, and if you choose to compile it yourself without that, then you can still check in but under a bit more of a microscope? Not sure how many people "roll their own" and compile things themselves.

Edit: on the other hand, all these are easy to spot an kill. Reporting results in other's names would be more dangerous, for example, imagine me reporting fake TF results for Oliver to discredit him... They would be difficult to spot, due to his high activity, and later create a lot of headache to re-check his (enormous amount of) work, when people will start to find missing factors in his reported results. Right now, nothing stop me to do so. We used to "trade credit" in the past, for example I was CPU-bottlenecked but had a lot of GPU power available, and I was doing and reporting TF work for other people who did and reported CPU work (DC) for myself, and there was nothing to stop us. I don't believe things changed ever since. That's why I said the CRC is the proper way to go...

To report results as someone else you'd have to do it in one of two ways...

• Know their login/password on the site and submit using the manual forms
• Configure your client with their login id and submit using the client (no password needed for that)

The first one is definitely a problem which is why you should pick good passwords.

The second one would be harder to exploit because the client is doing the communicating, and due to the aforementioned security hashes that Prime95 implements on the API side would be very hard to automate. You might as well actually do the work and submit it. LOL

Preventing fraudulent results from coming in probably won't be possible to totally stop, but we can do better. Detecting and removing them is feasible as we've seen, because of the "many eyes" who are quick to spot even some minor weirdness.

It's probably a good thing whenever we have these new prime discoveries and people go on their egg hunts, because they pore over the data looking for clues. That's the same type of analysis that helps find bad actors.

[chalsall]

Originally Posted by Madpoo

One glitch is that there are users who genuinely submit a LOT of results daily (think TJAOI or even the Gpu72 bot) so it might place an undue burden on them.

Just to note, the GPU72 bots never submit results; that's done by each individual worker's clients.

Originally Posted by Madpoo

Know their login/password on the site and submit using the manual forms.

Many years back, LaurV and I were trading work. He knew my primenet username (but NOT my password) and was doing TF'ing for me, and I knew his username and was doing DC'ing for him.

LaurV being LaurV, a few years later he played a joke on me, and submitted a tonne of (legitimate) DC work under my username, but somehow used a different Display Name.

[TheJudger]

Originally Posted by Madpoo

5520 TF results, all of them "no factor found". It'd be astounding to do that many and not find any factors, ya know? And making a point of specifying "1 to 82 bits", because all of them had been TF'd to at least some bit level in the 60's, haven't they?

Plus, with a line like this, doesn't this signify that the mfaktc build only goes up to 76 bits?

no factor for M900200747 from 2^1 to 2^82 [mfaktc 0.20 barrett76_mul32_gs]

Correct, that kernel can handle numbers up to 2⁷⁶. And the lower limit for all current barrett based kernels in mfaktc is 2⁶⁴.

Oliver

[kriesel]

Originally Posted by ATH

Limit how much credit a brand new account can turn in? Like max 1,000 GHz-days in the first week? or 10,000 GHz-days the first month? or whatever seems fitting.
Maybe 1000*x GHz-days where x is the age of the account in days.

GTX1080: rated at 1015.8 GhzD/day. Let's round to 1000.

So, one gtx1080-day/week (14% of TF throughput), 10/month (33% of TF throughput), cap of a user account to one gtx1080's TF throughput indefinitely?That would really hamstring any RTX2060 or RTX2080 owner's credit for contribution, or the top producers that run multiple systems and gpus. TheJudger is running the equivalent of 8 RTX2080 Ti's; 10⁷GhzD/year=~28,000GhzD/day. (Awful unit, that GhzDay/day; why not Ge, Gigahertz-equivalent? If you think the corporation GE might take exception, use G e or G.e or Ghe...)

The top couple dozen producers are each averaging over the past year, more than the proposed 1000 GhzDays/day cap, 365,000 GhzDays/year. Given the current gpu state of the art, a couple orders of magnitude higher threshold would be advisable, with adjustment occasionally as hardware designs advance. https://www.mersenne.org/report_top_500/ https://www.mersenne.ca/mfaktc.php
The last 24 hours of GIMPS was 175.5Thz. TheJudger alone averaged 27.7 over the past year. The 24th on the top producer list averaged a bit over 1Thz. The top 24 combined contributed over 108Thz over the past year, or more than 60% of the past day's total GIMPS throughput from all partiipants.

I suggest caution about removing or reducing incentives of the top performers. And all were once new users. Someone joining the project with a shiny new GTX 1080 Ti or faster gpu could get quickly disillusioned and leave, that might have become a very substantial contributor over time. There are consumer gpus on the market that will each produce more than triple the proposed 1000 GhzD/day credit cap.
Currently there is nothing in signup, manual assignment or reporting, that enables the user to indicate what their gpu computing capacity is, other than rolling gpu model name into computer name in mfaktx or gpuowl; in CUDALucas or CUDAPm1 nothing at all. So from some applications, the primenet server does not receive gpu model and have a basis for computing whether the rate of "results" is plausible. (sorry, earlier version had that backwards plus incomplete!)

[kriesel]

Originally Posted by TheJudger

Correct, that kernel can handle numbers up to 2⁷⁶. And the lower limit for all current barrett based kernels in mfaktc is 2⁶⁴.

Oliver

So, not just a counterfeit, but a redundantly easily exposed one. And claiming to have used older than the current released version. (Looking forward to 0.22 here...)

[kriesel]

Originally Posted by Madpoo

We've actually been chatting with Ernst about getting mlucas to be able to use the API (hope I'm not spoiling any secret there...and it may or may not happen), but part of that is that API usage for the most part is restricted to "secure" clients that send a valid security hash in the requests.

We can set Ernst up with his own key so the client/server can trust each other, but the problem comes in because of the need to be open source. I guess it could be like Prime95 where the security bits are not made public and you can build without it, with the net effect being it cripples the automatic communication. Or something like that... I vaguely recall that it adds "UNTRUSTED" to the result or some such.
...
It's probably a good thing whenever we have these new prime discoveries and people go on their egg hunts, because they pore over the data looking for clues. That's the same type of analysis that helps find bad actors.

As I understand it from reading Ernst's readme and the bare beginnings of getting started with mlucas myself, standard operating procedure has been that the end user compiles his own mlucas for his OS and hardware type. He's covering a range of Intel processors, AMD, and ARM.
Similarly, at least on the linux side of things, gpuowl and other gpu apps are generally end user compiled. I build Windows executables frequently for gpuowl and share them in the gpuowl thread.
Flashjh and others used to provide CUDALucas executables. Etc.

None of the gpu apps have interfaced the Primenet API or security code. I think there are some structural issues with the cpu-oriented primenet API that relate to that. I suppose one could give the primenet api fake properties for a gpu as a strange sort of single-core cpu to try to shoehorn it in.

[kriesel]

Please review https://www.mersenneforum.org/showth...845#post505845
Post 1: primenet practice in prime95 has outpaced the documentation
2: the existing API is cpu and prime95 oriented, which does not fit gpu applications well
3: early incomplete draft regarding extending the primenet API to support gpu applications, including multi-gpu per system configurations.