Old data flushing...given 2 times credit for

[MarcyDarcy]

[oke this is gonna be al long story to make it all clear...don't punish me :)]

I was started flushing some saved data (arount 500K), but when the new protein was updated the uploading stopped. (some kind of error i don't remember...client closed himself)

After downloading the update for the new client, i wanted to get credit for my work what i was uploading. So i copied a backup into the new folder and started uploading again (from the beginning...again the 500K)

But when i was watching the Distributed Folding stats updating every 10 minuts, i saw that i was given more credit for then i thought i deserved. What i mean...before the clientupdate i think that he was over the 50% of the 500K. But i saw when i was "reflushing" that i got credit for almost 500K

Not completely conviced that i coused the increase (because we have a couple of users flushing under the same account) i waited for 20 minutes (2 statsrun) en saw that there wasn't a hughe increase of our total. So i decided to "reflush" another folder wich i took from my work (no internet). I had completely flusht it before the clientupdate but wanted to know if there is an error/bug in you statssystem.

I planted the backup folder in the "current folder with the updated client" en started flushing again. I waited 2 statsruns to see i fi coused the increasy en unfortunately i think i coused it.

To make the story clear...after a clientupdate it's possible to cheat by "dubbelflushing" old data witch was given credit for before the clientupdate.

I think after the clientupdate the statsserver isn't checking for "older and given credit for data"

Hope you understand what i mean and that you will look into this situation

--------

Every user who reads this..please don't try it for yourself. Let the people behind the project look into it

[Brian the Fist]

Perhaps this would have been best to mention in a PRIVATE e-mail, but I figured someone would notice eventually, just not so quickly. Yes, you are right, and this is a 'feature', not a bug. Because we only use a checksum to detect duplicate data, we don't want to keep all the checksums from old proteins as they might eventually duplicate, even though its a different data file, eventually. We trust most people are honest and won't try this but if we find it a problem, we can always revoke the ability to upload the previous protein again ;)

[MarcyDarcy]

After i writen this topic, i've posted also on our forum. One member of ours said he already knew this. He had discovered it about 20 days ago. He said you already knew about this. But that doesn't realy matter.

The cheat/feature i've writen about inhere is only possible at some moments (after a new clientupdate) so i thought i could post it overhere.

Hmm you're speaking of a feature, i think that is a little bit too good. There will always be people wanted to increasy their totals by cheating. Why don't block this intention?

The option to upload older data is perfect, but can't you make a sort of dual statsdatasystem. We're talking about the option to flush older data after 24 hours (at 100%) and after another 24 hours (at 50%) if i'm correct. If this is true, can't you leave the old data stored for 48 hours and then delete the not usefull ones (and keeping the Best pseudo-energy).

It will cost some hd space but this way the abuse of this feature isn't possible. The stats are not the most important but also the fact that there will be an abuse of bandwith, hd space and the useless medical data (because it is already been send).

Hope you understand my oppinion (and the most of the team)

----------

In a few hours, i'm sending you an email because after my post on our forum, we started looking at some other ways to "cheat". And yes...we have found one :eek:

[MarcyDarcy]

Hmm...i got an remark on the last sentence from a teammember. We are not trying to cheat of something. We hate the idea of anybody is cheating.

We ware worried because that other option (the feature) cathed our attention and we want to make this realy good & fun project some little bit better. So we begon "bugtracking" to see what else we could discover that you've mayby missed/overlooked :)

[MarcyDarcy]

i tried to email you, but i can't find your emailadres.
The option in this forum doesn't work (i don't have permission) :cry:

[jlandgr]

Originally posted by MarcyDarcy
i tried to email you, but i can't find your emailadres.

I think you can use trades@mshri.on.ca
(address from the distributedfolding.org site)
Correct me if I'm wrong,
Jerome

[runestar]

Originally posted by Brian the Fist
Perhaps this would have been best to mention in a PRIVATE e-mail, but I figured someone would notice eventually, just not so quickly. Yes, you are right, and this is a 'feature', not a bug. Because we only use a checksum to detect duplicate data, we don't want to keep all the checksums from old proteins as they might eventually duplicate, even though its a different data file, eventually. We trust most people are honest and won't try this but if we find it a problem, we can always revoke the ability to upload the previous protein again ;)


I discovered this on my own too, although I won't go into the exact details of how I did or the method of doing it. I am gravely concerned that there could potentially be people out there abusing this.

So the question that really wasn't asked or answered is: How are you checking for abuse of the feature?

Granted its useful if the client crashes...but considering the number of people who have publicly noted they discovered this feature, whose to say those who haven't said anything aren't abusing this?

It seems to me that the problem could at least be partially solved if DF offered crash recovery. For some reason, it seems the screensaver is much more adept at this even though the command line is suppose to be the main client. Although because it crashes on AMD systems, it makes difficult to test. But back to the main point, frequently old work is lost with seemingly no way to recover it.


RuneStar½
PBB