Take a look at the top participants (https://boinc.bakerlab.org/rosetta/top_users.php) and check out number 1. This can't be right. It seems that granting credit is really screwed.

Can this be fixed a.s.a.p. (I suggest deleting the user) because this is messing up both Rosetta and BOINC combined stats.

---

He could be overclocking! ;-))

---

Or he could have "optimized". ;)
hahaha

I have changed some update code, and this specific user gets 0 (zero) credits when imported into the BOINCstats DB until his credit is fixed.

---

Take a look at the top participants (https://boinc.bakerlab.org/rosetta/top_users.php) and check out number 1. This can't be right. It seems that granting credit is really screwed.

Can this be fixed a.s.a.p. (I suggest deleting the user) because this is messing up both Rosetta and BOINC combined stats.

There is a trivially easy exploit that can be done on a project like Rosetta where there is no redundancy that can be used to check credit claims.

No, I am not going to publish it here. If any of the BOINC or Rosetta admins email me I can explain further but if you are in contact with any ex-Pirates they may well remember it being discovered on that project.

Whether it is an exploit or a bug, a half-fix is to impose a max credit for WU based on the max runtime, this would ideally be a change to the BOINC server code.

Users who exceed this limit should get logged so that in extreme cases admins can easily do a manual check for bug or malice.

In the absence of a manual check the user should get zero for that run. After a manual check fair credit can be added manually if it was a bug. If it's fraud all past credit for that user should be cancelled in my opinion.

In fairness this does not look like deliberate fraud - with some of the funny WU that have been released here recently it could be a machine induced glitch. The admins will be able to tell quickly if it is just one WU, or several WU from one user, or several wu from several users.

edit:
I would have thought that a deliberate fraud would have been more subtle, like at the very least asking for a numerical amount of credit!

The exploit does need working round, however, unless this has already been done.

---

I have changed some update code, and this specific user gets 0 (zero) credits when imported into the BOINCstats DB until his credit is fixed.

A better long term thing would be to install some sanity checking to give zero credit for any credit that is misformatted or exceeds some (generous) max plausible figure. That way future problems of a similar nature will not make you have to hack your code on Christmas day!

Maybe you'd still want to log such things so that you can give similar alerts to the relevant project team(s)

River~~

PS- as a BOINCstats user, thanks for the service in general and for providing Christmas maintenance cover :-)

---

A better long term thing would be to install some sanity checking to give zero credit for any credit that is misformatted or exceeds some (generous) max plausible figure. That way future problems of a similar nature will not make you have to hack your code on Christmas day!

But what is a plausible figure? This would be different for every user. Of course, this one went a bit over the top. Just a bit.

PS- as a BOINCstats user, thanks for the service in general and for providing Christmas maintenance

They call me 'no-life-Willy'. Well, sometimes they do. Mostly at work.

---

But what is a plausible figure?

myself, i'd select the total credits for each project, then use the highest of those figures as a cut off for the next days credits for any single user on any single project. That makes a safely large and obviously implausible cut-off point.

There are other ways to generate a figure from yesterday's data - any such data-generated limit would be safe for any normal future development because it will scale up as Moore's law pushes the credits ever higher.

It won't catch all errors, no sanity check can catch a subtle cheat, but a value in the zillions should not get through, in my opinion. Some errors that get through would still distort the stats, but not in such an extreme way as this one did.

R~~

But what is a plausible figure?

Average CS per second of recent work returned * CPU seconds * 3

THat gives a generous margin of error, trimming 3 to 2.25 or what ever if you want a tighter test than 50%.

==== edit

Or just bite the bullet and FLOP count ... :)

---

---

Any "check", no matter how good, other than flops-counting or redundancy, is just a patch.

more like a fuse than a patch I'd say

Certainly a check is not a solution; but it should be installed before a solution comes along, and should be kept after a solution comes along as a safety device.

And you are right, we need a solution as well as the fuse.

River~~

Can this be fixed a.s.a.p. (I suggest deleting the user) because this is messing up both Rosetta and BOINC combined stats.

LOL get ready to be flamed! Some people here really take the mickey if you start claiming this or that person is cheating. See the 'cheating' thread I started a while back.

Personally I quit the project 2 weeks ago and will only come back once the stats are fair. It's been proven the stats can be altered even without modifying the client at all. If people are cheating 'intelligently' (ie, not claiming a billion credit but 20 or 30% more instead), then it's undetectable.

Edit: I was about to say 'next thing you know they'll tell you it's just a glitch because of a bad WU' - and they did. :-D

---

Team CFVault.com
http://www.cfvault.com

Can this be fixed a.s.a.p. (I suggest deleting the user) because this is messing up both Rosetta and BOINC combined stats.

LOL get ready to be flamed! Some people here really take the mickey if you start claiming this or that person is cheating. See the 'cheating' thread I started a while back.

Personally I quit the project 2 weeks ago and will only come back once the stats are fair. It's been proven the stats can be altered even without modifying the client at all. If people are cheating 'intelligently' (ie, not claiming a billion credit but 20 or 30% more instead), then it's undetectable.

Edit: I was about to say 'next thing you know they'll tell you it's just a glitch because of a bad WU' - and they did. :-D

<aside>
Wondered where you've been; haven't seen you around the boards for awhile. Miss your contributions here in the discussions. Come back soon. If not 100% Rosetta what are you doing?
</aside>

LOL get ready to be flamed! Some people here really take the mickey if you start claiming this or that person is cheating. See the 'cheating' thread I started a while back.

Some people have now been pointed out that actually appear to be cheating; _this_ particular one I don't think is, or if he is, he's incredibly bad at it.

Personally I quit the project 2 weeks ago and will only come back once the stats are fair. It's been proven the stats can be altered even without modifying the client at all. If people are cheating 'intelligently' (ie, not claiming a billion credit but 20 or 30% more instead), then it's undetectable.

That is of course your choice; discussions on the issue are continuing behind the scenes, and I'm pretty sure you'll be able to return fairly soon... :-)

Edit: I was about to say 'next thing you know they'll tell you it's just a glitch because of a bad WU' - and they did. :-D

If you're referring to _my_ comment, I said it was likely a bad run of the benchmarks - there is no way a WU could cause this... the only mention of WUs in this thread is on how to check one to see if the credit claimed is reasonable.

---

I removed the host and alerted the user about the problem and suggested not to run the project on that particular computer until the cause of the problem was determined. I do not think it was cheating but a bug (possibly in the client that was used on that particular computer) that caused the ridiculously high credit granting.

I'm in this project for the science, so it doesn't bother me one way or the other is someone is cheating on the credits. As long as they are not cheating the science.

---

discussions on the issue are continuing behind the scenes, and I'm pretty sure you'll be able to return fairly soon... :-)

I like the sound of that :-D

---

Team CFVault.com
http://www.cfvault.com

I'm in this project for the science, so it doesn't bother me one way or the other is someone is cheating on the credits. As long as they are not cheating the science.

the only problem with that is with those who crunch for (fair) credits, because they then (rightly) claim that the credits are meaningless, and aren't as willing to crunch anymore, a lot of CPU power comes from these "uber-crunchers" so the credit system has it's uses

It's also good to compare your production rate to others, for example without RAC (i know it's not accurate, but it gives a rough idea) how would you compare a user with 5 hosts, and a user with 7 hosts

I'm in this project for the science, so it doesn't bother me one way or the other is someone is cheating on the credits. As long as they are not cheating the science.

the only problem with that is with those who crunch for (fair) credits, because they then (rightly) claim that the credits are meaningless, and aren't as willing to crunch anymore, a lot of CPU power comes from these "uber-crunchers" so the credit system has it's uses

It's also good to compare your production rate to others, for example without RAC (i know it's not accurate, but it gives a rough idea) how would you compare a user with 5 hosts, and a user with 7 hosts

For me it is not either/or.

I am not in it for the credits but for the science.

But I do like my contribution to be recognised and with thousands of hosts the credit system is one practical way to do it.

I might not have done the washing up for the thanks; but if kid bro got thanked when I did it, *then* I got upset.

R~~