Not that I condone this sort of thing of course, but.....

Since Rosetta grants credit purely based on claimed credit (and a successful result I assume) then it leaves itself open to cheating for credit in a BIG way. All someone has to do is artificially inflate their benchmarks, which causes artificially high claimed credit and hence granted credit is also artificially higher than the computer should be granted! In this case the science isn't altered, but the kick in granted credit will be a magnet for the cheaters in this world.

Live long and crunch.

(ps. surely this has been discussed before).

---

PPaul
(S@H1 8888)

Do as I say, not as I do!

Doh...I just read David's post...yes it has been discussed before.

As the OP said, it's nothing new... but I reckon that we are now approaching the point where cheating might become widespread (see my previous post on the redundancy thread). It just needs someone to release a client with inflated bench numbers.

I'm going to stick with Rosetta regardless but I think it's time anti-cheat procedure be put in place.

---

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

Which is going to be a problem unless and until we do something like my proposal using double-blind benchmark testing. FLOPS counting sounds like a cure, but all I have to do is edit the data counted and I can "cook" the books again ...

Well, we shall see if anything is done. Sad to say, until and unless the projects begin to ask for changes and improvements it is not likely we shall see anything happening (unless a C++ coder comes along and does it for us).

---

@stephan_t: you dont even need to compile your own core client. The bog standard app will claim off-the-chart credit if you want it to. (takes a couple seconds to set up!!)

@paul D.B: I read your proposal and it sounds very interesting. Would certainly make cheating alot harder and would make the granting process much fairer for everyone

cheers,

Paul.

---

Wanna visit BOINC Synergy team site? Click below!

Join BOINC Synergy Team

Well, we shall see if anything is done. Sad to say, until and unless the projects begin to ask for changes and improvements it is not likely we shall see anything happening (unless a C++ coder comes along and does it for us).

I'm slowly digging into the Boinc sources, I already have one small change in the works that a number of Windows users have asked for. Couple of questions come to mind:

1. How do I send my modifications back to Boinc "home base" so that they can be audited, and if found to be OK, integrated into the main code base.

2. What exactly is the nature of the changes that would be needed to try to help solve the "cheating on benchmarks" problem?

As it is, I understand the current nature of the beast is that credit is handed out based on (Time taken * Benchmark numbers). So if I cheat and increase the benchmark numbers, I get more credit.

It seems to me that what you have in mind is some way to actually monitor the number of FLOPS done by the CPU, and use that as a metric to determine credit. On the Mips (at least the one in the PS/2), they have registers that will count this sort of stuff for you without slowing down the CPU. As far as I know, there's no corresponding mechanism on the X86 architecture, which is where a good percentage of Boinc lands. OC I could be wrong about that .....

P.S. I'm a C++ coder. :)

---

1. How do I send my modifications back to Boinc "home base" so that they can be audited, and if found to be OK, integrated into the main code base.

Email davea at ssl dot berkeley dot edu

---

BOINC WIKI

You should also consider joining the BOINC development email list:
http://www.ssl.berkeley.edu/mailman/listinfo/boinc_dev

---