Message boards :
Number crunching :
Report Cheating
Message board moderation
Author | Message |
---|---|
![]() Send message Joined: 18 May 99 Posts: 18 Credit: 53,634,823 RAC: 0 ![]() |
|
Astro ![]() Send message Joined: 16 Apr 02 Posts: 8026 Credit: 600,015 RAC: 0 |
you can report it here if you like. I don't know of any official method to do so. you could write to setidba@ssl.berkeley.edu, but I know they're swamped with mail since classic shut down. If you give links to your proof, others would certainly make comment. tony |
![]() ![]() Send message Joined: 21 Oct 99 Posts: 2246 Credit: 6,136,250 RAC: 0 ![]() |
at BOINC you and others have to calculate, at least 3 Results i think this is not so easy with at SetiClassic if yo found somethink that we dont know an e-mail at <a href="mailto:ulrichbrinkschmidt@teleos-web.de"><img src="http://home.teleos-web.de/ubrinkschmidt/screen/email.gif"></a> would help so i can report this to David Anderson edit E-Mail ulrichbrinkschmidt@teleos-web.de Greetings from Germany NRW Ulli ![]() ![]() |
![]() ![]() Send message Joined: 25 Jul 05 Posts: 141 Credit: 25,742 RAC: 0 ![]() |
How does cheating happen at all? ... and to what end do people think cheating is necessary? What, showing off some sort of skill? Save it for some other game, for cryin' out loud. We're trying to get some serious Science done over here. You won't get a trophy for having so many credits. You just get bragging rights. .. and cheaters never win. Karma'll come and bite you in the @$$. :p Have a nice life. It won't be easy, you rackin' up negative karma like you are. I'm only partly glad that scum like you exist -- cuz then we have a basis for comparison, so that the rest of us know we're not scum. Hah! *Thanks*! .Cx. Disclaimer: This is not a flame. I don't flame. I just share opinions openly. :p For those who are NOT scum, this will not apply, and can be ignored. For those who ARE scum, they will take this as a compliment. Besides, I said "thanks", and I didn't use foul language. ;) |
![]() Send message Joined: 3 Apr 99 Posts: 1603 Credit: 2,700,523 RAC: 0 ![]() |
Lets see some details of this alleged cheating before we all go off on one. If Alaskan would care to share the information here then we can evaluste it. The Developers will also get to hear of it if necessary. ![]() |
![]() Send message Joined: 14 May 99 Posts: 65 Credit: 18,370,396 RAC: 0 ![]() |
Hard to cheat with how they calculate credits given. Number of results returned have to match a hard to duplicate class of checksum for EACH WU, and if they dont validate with OTHER returns, their ignored. Submitting false claimed credit amounts wont help you much either. Each WU is sent to 4 people, and 3 results are required that validate before credits are given, and its not the high/low credit claims but the MIDDLE of those 3 returns that all 4 will get. So you can see, cheating would probably require hacking the cottenpickin database. ![]() |
![]() ![]() Send message Joined: 8 Sep 05 Posts: 1386 Credit: 200,389 RAC: 0 ![]() |
Hard to cheat with how they calculate credits given. I agree...BOINC is open sourced, there are optimized clients for SETI and prolly other projects and you can have several computers analyzing WU's.Optimized MIGHT be considered cheating, and altering BOINC MIGHT be considered cheating, and using 20 computers MIGHT be considered cheating, but given that all those methods ARE allowed, how can we define cheating? I don't know that there really is a way to "cheat" or if it is at all possible...although with more info we MIGHT be able too tell............ "By faith we understand that the universe was formed at God's command, so that what is seen was not made out of what was visible". Hebrews 11.3 |
![]() Send message Joined: 19 Jul 00 Posts: 3898 Credit: 1,158,042 RAC: 0 ![]() |
There are a number of ways to influence the system (cheat), but, the ability to efffectively gain much from these exploits is fairly low. The first screen is that the work has to be downloaded and processed into a valid result. So, that eliminates the largest part of the prior exploits where work could be "cloned", cherry checked, or recycled. Since these were the primary ways that scores were inflated this is a pretty decent advance. You can "cook" the books on benchmark scores to inflate claims, but, on most projects this matters not because the claim averaging of the quorum removes most of the influence of these. For CPDN it matters not at all because they use flat rate rewards, Prime Grid caps the claims, leaving only Rosetta@Home where this can still be pursued with some potential. Again, the system is not perfect, but, it IS pretty good in limiting the effects of the most egregious attempts |
![]() Send message Joined: 30 Jul 03 Posts: 7512 Credit: 2,021,148 RAC: 0 ![]() |
The standard client is a plain vanilla generic one sizes fits all. Optimized clients are CPU/OS specific. Therefore they increase the benchmark results. Although they may return a higher credit score, that is attenuated by the other results. Optimized applications do much the same thing for the project which they are crunching. An optimized app will crunch the same WU in a much shorter time, and ask for less credit, and therefore balance out. More WU's which are crunched increases the amount of work done for the project. That's the short story in simple terms. Most advanced users on the project are using one or both. That would make for a very large group of cheaters. Unfortunately, Jason, your PII is probably a MMX at best, and would only get a comparitively small boost in performance. Account frozen... |
Bob Guy Send message Joined: 7 Sep 00 Posts: 126 Credit: 213,429 RAC: 0 ![]() |
I think we can assume the credit system is total baloney! I still process workunits (SETI and other projects as well) only because I think the science is important. I am offended, though, when I find computers claiming 3 to 6 times the credit for the same work. Just look at this: Measured floating point speed 6292.45 million ops/sec Measured integer speed 8453.17 million ops/sec The above was reported from a BOINC client labeled 5.2.6 for a P4 2.8 and results in a claim 6 times what my computer has recently claimed for similar work. This kind of thing is just outrageous. With all the hacked BOINC clients the client version numbers are meaningless. Any fool can produce a client that will claim any arbitrary amount of credit. And, to argue that the quorum of results will even out the credits is naive. There are enough 'rogue' clients so that 3 or 4 will appear together in a quorum often enough to skew the credits granted toward the larger values for those machines. It's true that I will also sometimes benefit. But with Rosetta@Home that argument fails altogether. The machine for which I retrieved the speeds above is consistently granted these inflated credit claims for ALL the SETI workunits it does. So where is the 'It all evens out in the end'? I have also recently seen what may be a new credit exploit. I have found a Pentium machine (or machines) that appears to be running at a 100% overclock - I mean the it must have a system clock that is 2 times the normal clock. I wouldn't have expected that an Intel chip could be overclocked that much. I suppose it's possible with exotic cooling solutions but it's very hard to believe. In addition it claims 4 times the credit for the very same workunit I've processed using the very same science app. It is more likely that this machine (or machines) is not what it says it is and may very well not even exist. I can only think that this machine (or machines) exist for the sole purpose of obtaining inflated credits. I have been deliberately vague about the computers and numbers above because I don't want to point fingers. After all, I could be wrong or overreacting. Anyway, I'm here for the science, not the credits. All these machines, while asking for more credits than (I think) they deserve, are actually producing useful science results (hope so anyway). But I'm still offended by the greed and sad but not surprised that such a thing exists. Thanks for listening to my rant - I feel lots better now. |
![]() ![]() Send message Joined: 8 Feb 04 Posts: 350 Credit: 1,015,988 RAC: 0 ![]() |
nice rant, I enjoyed reading it. heck, I even agree with some of it, but I am only going to comment on this bit: {snip} It is possible to get "extreme" overclocks with Intel chips, just take a look at this verified CPU-Z screenprint. No extreme cooling is involved, just the stock Intel Wind Tunnels. These CPU's stay under 40C under full load. With a higher core voltage they should be good for 3.2GHz, but I'm happy with them as they are now. |
![]() ![]() Send message Joined: 24 May 00 Posts: 334 Credit: 204,421,005 RAC: 15 ![]() ![]() |
This is a good way to claim higher credit. But "Granted" is different. Lower and Higher claimed are not in count, when granted is calculated.
This, instead, it's a good way to claim LESS credit, because if you take less seconds (half) to complete one result, you will claim half credit. Claimed Credit is (Measured floating point speed + Measured integer speed) * seconds of CPU Work. So, in the first case, they claim more than they will be granted and in the second case they claim less than they will be granted. Bye, Francesco |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13917 Credit: 208,696,464 RAC: 304 ![]() ![]() |
And, to argue that the quorum of results will even out the credits is naive. There are enough 'rogue' clients so that 3 or 4 will appear together in a quorum often enough to skew the credits granted toward the larger values for those machines. I wouldn't consider "once in a blue moon" to be of even the slightest bit of concern as far as the handing out of credit is concerned. Grant Darwin NT |
Jack Gulley Send message Joined: 4 Mar 03 Posts: 423 Credit: 526,566 RAC: 0 ![]() |
The only effective scheme for large scale cheating that would not be detected and filtered out to some degree would require either someone with a very large number of systems setting up separate accounts for them, or a large number of people working as a group with their different accounts. To be of any real cheating value, they would have to be organized into a Team and cheating for a Team, not an individual account. By setting large cache sizes they could download large numbers of WU at about the same time. Then compare WU ID's across their base of systems. For any match of two or more found, one system could processes that WU on a priority bases and pass its results to the other systems with the same ID, each inflating their claimed credit and time by slightly different amounts to avoid detection. Then send those results in early to make sure they form part or all of the quorum for that WU. This out of sequence reporting in itself could draw attention, but is necessary if only two results of a WU are caught by the network. The rest of the WU would still have to be processed or that would draw a lot of attention. The draw backs of attempting this, is that it really only benefits a Team, it takes a lot of work, although much of it could be automated, it might attract attention and questions if credit claims are two high, and it would not inflate the credits all that much considering the work involved. The only big gains that would occur and not attract attention is when this network of systems happened to catch all four results of a WU and fake results quickly inserted which pass the validator. With the new client coming out, its new operations counting feature for determining credit should deter most cheating regarding claimed credits. All valid results should claim about the same amount of credit. With the current method and clients, if other idle processes are running at the same time, credit claims can be greatly inflated because of the longer measured run time. This happened if you ran BOINC/Seti and Seti Classic at the same time. The BOINC WU could take almost ten times longer to run and claim almost ten times the credit. But calling these high claims cheating is subject to debate, as it actually took that much time to do the result. You might also get the same effect by running two or more copies of BOINC at the same time. The credit claimed by each instance of the client would be multiplied by the number of instances of the client running. This being done by any high credit returned account would look suspicious and would be easy to detect over time. |
Ingleside Send message Joined: 4 Feb 03 Posts: 1546 Credit: 15,832,022 RAC: 13 ![]() ![]() |
With the current method and clients, if other idle processes are running at the same time, credit claims can be greatly inflated because of the longer measured run time. This happened if you ran BOINC/Seti and Seti Classic at the same time. The BOINC WU could take almost ten times longer to run and claim almost ten times the credit. But calling these high claims cheating is subject to debate, as it actually took that much time to do the result. Since BOINC uses cpu-time, while run-times can be 10x as long the reported cpu-times will only be slighly increased. Only on win9x that doesn't know anything about cpu-time would this be an issue. |
![]() Send message Joined: 25 Nov 01 Posts: 21688 Credit: 7,508,002 RAC: 20 ![]() ![]() |
The only effective scheme for large scale cheating that would not be detected and filtered out to some degree would require either someone with a very large number of systems setting up separate accounts for them, or a large number of people working as a group with their different accounts. To be of any real cheating value, they would have to be organized into a Team and cheating for a Team, not an individual account. That is a plausible cheat that could be easily scripted on a *nix network or cluster. An easy and quick defeat for that is for Boinc to include an encrypted key as part of the result to be returned that includes at least a unique timestamp, WU-id, and host-id, or just a unique hash number. (To avoid a cryptographic attack, any serial numbers should NOT be sequential! But then, processing the WU would likely be far easier than breaking the encrypted key!!!) Is this done already? A one-way hash/key would be easy and fast. Regards, Martin See new freedom: Mageia Linux Take a look for yourself: Linux Format The Future is what We all make IT (GPLv3) |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 ![]() |
Anyway, I'm here for the science, not the credits. All these machines, while asking for more credits than (I think) they deserve, are actually producing useful science results (hope so anyway). But I'm still offended by the greed and sad but not surprised that such a thing exists. I submit that 90% of the time, these problems are simply related to the benchmark. A benchmark is a program or routine that does no useful work, other than to assess the CPU. As has been observed, the benchmark fits entirely in the cache on some CPUs and does not fit in the cache on others. Some CPUs are simply better at running the benchmark. At least one system out there is so fast that the benchmark finishes unbelievably quickly. Benchmarks are, and have always been, imperfect (going back to the earliest attempts at benchmarks -- 30 years or more). That said, if four results come in with requested credits of 50000, 26, 24 and 3, the work unit will be granted 25, no matter how inflated that high score might be, and no matter how low the lowest might be. |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 ![]() |
It would be trivially easy to replace the BOINC benchmark with something that simply returns a value. ... and someone who tweaks the benchmark that way can insure that they're always the highest score. So, let's assume a machine that should request about 20, and instead requests 100,000. Two other machines request 15 and 30. Granted credit should be 20, because the high machine (30) and the low machine (15) would get thrown out. Instead, granted credit is 30, because the requests for 100,000 and 15 are discarded. The "cheater" got himself an extra 10 points, as did the other two "unwitting accomplices" Pair him with two "lesser" machines, say the requests were 15 and 18 (and 100,000 instead of 20) and granted credit would still be 18. Average it over a few thousand work units, and the advantage is pretty small. This kind of an attempt at cheating simply inflates granted credit overall. |
![]() Send message Joined: 3 Apr 99 Posts: 1603 Credit: 2,700,523 RAC: 0 ![]() |
It is of course trivial to just edit the benchmark figuers in client_state.xml. It only needs repeat editing every week after the regular benchmark. What's more amazing than the possibility of cheating is this thread now has 18 replies, all generate by a single unsubstantiated throwaway comment, which the OP considered so important that he hasn't bothered to return. Sad. ![]() |
![]() ![]() Send message Joined: 4 Dec 03 Posts: 1122 Credit: 13,376,822 RAC: 44 ![]() ![]() |
That is a plausible cheat that could be easily scripted on a *nix network or cluster. Not really... it's _possible_, but if any "board regular" suddenly got hundreds or thousands of credits from one result, because the others in the quorum were all from this "cheating team", it would be detected and reported pretty soon. Remember, a _single_ user could not do this. It would require a minimum of two and ideally at least three accounts, all getting the _same_ WU assigned, and all being members of this "team". And the question comes back - for what? Why would someone bother with all that work, just to get a higher spot in the standings, _if_ they didn't get caught? As far as the scripting part goes - it'd be easier to just modify the BOINC daemon itself to communicate with the other cheating hosts and "cherry pick" the matching WUs. And - even if other quorum members never reported it, a simple SQL query against the results database on the server side would identify anyone doing this. Maybe five minutes to write, an hour or so to execute, and their credits would be history. |
©2025 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.