Re: Mersenne: TF - an easy way to cheat
- Original Message - From: Torben Schlüntz [EMAIL PROTECTED] To: Daran [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, September 21, 2002 11:17 PM Subject: SV: Mersenne: TF - an easy way to cheat But my name is Torben... My apologies. With an unusual spelling to my own name, I usually try to avoid making this mistake with others. But on this occasion I slipped up. What is POV? Sorry. Point Of View. Regards Daran G. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: TF - an easy way to cheat
On Friday 20 September 2002 22:42, Torben Schlüntz wrote: Anyone receiving a TF task could edit the worktodo.ini from Factor=20.abc.def,59 to Factor=20.abc.def,65 He would receive approx. twice the credit the effort is worth. Not quite - even allowing for the 1/2^6 effort involved in TF through 59 bits ... through 64 bits the algorithm runs much faster than it does for 65 bits and above. The factor is around 1.6 rather than 2. Ofcourse nobody would do this, as we are all volunteers! Or could somebody some day be tempted to raise his rank using this method? Never underestimate what some people may do to rig league tables! Does GIMPS hold some log for TF's done by which account? If so could this log please be open? I think the log exists but, since intermediate checkpoints are not logged, it might not show anything. Would this cheat be trapped later by P-1 or does P-1 trust earlier work so factors below say 67-bits are not considered? P-1 doesn't care what (if any) TF has been done previously. _Some_ but by no means all missed factors would be picked up bt P-1. Note also that some factors may be missed due to genuine glitches as opposed to deliberate skipping. The above questions are _not_ asked because I intend to use the method. :-/ I think it would miscredit GIMPS as we trust the results of GIMPS. And I would be disappointed if I learned that an LL I did could have been solved far earlier - and using less effort. Yes - but as TF is primarily designed to reduce LL testing effort, missed factors are an inefficiency rather than a serious problem. Suggestion: TF should report completion of each bit to PrimeNet, not just the on completion to the target depth. I don't see how this would require changes to the server, though there would be a (relatively small) increase in load. Suggestion: the TF savefile should be modified to contain an internal consistency check (say the MD5 checksum of the decimal expansion of the current factoring position) so that cheating by editing the savefile, causing jumping past a large range of possible factors, would be made a great deal more difficult. Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: TF - an easy way to cheat
Anyone receiving a TF task could edit the worktodo.ini from Factor=20.abc.def,59 to Factor=20.abc.def,65 He would receive approx. twice the credit the effort is worth. In fact the probability of finding a factor would be less than one sixth. [...] Would this cheat be trapped later by P-1 or does P-1 trust earlier work so factors below say 67-bits are not considered? P-1 doesn't 'trust' the amount of TF, in the sense of failing to find (or ignoring) small factors. However the calculation of the probability of success - and hence of the optimal bounds - assumes that none will be found. P-1 and TF search different but overlapping factor spaces. My understanding is that P-1 has about a 1 in 3 chance of finding a factor in the TF range. However I don't think the server logs who finds a factor, or how it was found, or even if the exponent was assigned to the finder. The above questions are _not_ asked because I intend to use the method. :-/ I think it would miscredit GIMPS as we trust the results of GIMPS. Factorisation is merely a tool for quickly eliminating candidates. We do not double check negative results as a proof that there are no factors in the checked range (though found factors are checked by the server itself). And I would be disappointed if I learned that an LL I did could have been solved far earlier - and using less effort. One way to avoid this disappointment personally would be to focus solely upon TF or P-1. br tsc Daran G. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: TF - an easy way to cheat
On Sat, 21 Sep 2002 16:33:04 +0100, Daran wrote: One way to avoid this disappointment personally would be to focus solely upon TF or P-1. To the best of my knowledge, there is no way in my version (22.8.1) to set the client to do only P-1. Nathan _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: TF - an easy way to cheat
One way to avoid this disappointment personally would be to focus solely upon TF or P-1. To the best of my knowledge, there is no way in my version (22.8.1) to set the client to do only P-1. Read undoc.txt in your Prime95 directory: You can force prime95 to skip the trial factoring step prior to running a Lucas-Lehmer test. In prime.ini add this line: SkipTrialFactoring=1 Jacek Kolonko smime.p7s Description: application/pkcs7-signature
Re: Mersenne: TF - an easy way to cheat
- Original Message - From: Brian J. Beesley [EMAIL PROTECTED] To: Torben Schlüntz [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, September 21, 2002 8:51 AM Subject: Re: Mersenne: TF - an easy way to cheat On Friday 20 September 2002 22:42, Torben Schlüntz wrote: Anyone receiving a TF task could edit the worktodo.ini from Factor=20.abc.def,59 to Factor=20.abc.def,65 He would receive approx. twice the credit the effort is worth. Not quite - even allowing for the 1/2^6 effort involved in TF through 59 bits ... through 64 bits the algorithm runs much faster than it does for 65 bits and above. The factor is around 1.6 rather than 2. Good point, and one which I didn't consider in my reply. But the ratio must be different for the P4, which uses SSE2 code for factorisation over 64 bits. Suggestion: TF should report completion of each bit to PrimeNet, not just the on completion to the target depth. I don't see how this would require changes to the server, though there would be a (relatively small) increase in load. According to undoc.txt:- You can limit how far the program tries to factor a number. This feature should not be used with the Primenet server., which implies that something bad will happen if you do. Suggestion: the TF savefile should be modified to contain an internal consistency check (say the MD5 checksum of the decimal expansion of the current factoring position) so that cheating by editing the savefile, causing jumping past a large range of possible factors, would be made a great deal more difficult. Easily cracked. Why not just encrypt it? Regards Brian Beesley Daran G. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: TF - an easy way to cheat
- Original Message - From: Jacek Kolonko [EMAIL PROTECTED] To: GIMPS [EMAIL PROTECTED] Sent: Saturday, September 21, 2002 5:38 PM Subject: RE: Mersenne: TF - an easy way to cheat One way to avoid this disappointment personally would be to focus solely upon TF or P-1. To the best of my knowledge, there is no way in my version (22.8.1) to set the client to do only P-1. Read undoc.txt in your Prime95 directory: You can force prime95 to skip the trial factoring step prior to running a Lucas-Lehmer test. In prime.ini add this line: SkipTrialFactoring=1 That's not what Nathan meant, and it would have the opposite effect of what Torban wants, which is to guarantee that he never LLs an exponent which has not had a full factorisation effort. Nathan is correct that the client can't be set only to do P-1. I achieve this effect by setting SequentialWorkToDo=0, and by ensuring that it never runs out of exponents to P-1. This requires continual hands-on management, collecting new exponents, and unreserving completed ones. One advantage of this, from Torban's POV, is that his chance of finding a factor through P-1 is *increased* if it has not been properly TFed. Jacek Kolonko Daran G. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
SV: Mersenne: TF - an easy way to cheat
That's not what Nathan meant, and it would have the opposite effect of what Torban wants, which is to guarantee that he never LLs an exponent which has not had a full factorisation effort. Your are truly right, Daran. But my name is Torben. And not Torban. Torben means the the bones of the great god THOR. This god is responsible for the ligthning. And is next to the superior god ODIN. :-) One advantage of this, from Torban's POV, is that his chance of finding a factor through P-1 is *increased* if it has not been properly TFed. What is POV? br tsc _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: TF - an easy way to cheat
On Saturday 21 September 2002 16:15, Daran wrote: ... through 64 bits the algorithm runs much faster than it does for 65 bits and above. The factor is around 1.6 rather than 2. Good point, and one which I didn't consider in my reply. But the ratio must be different for the P4, which uses SSE2 code for factorisation over 64 bits. Pass, I haven't let my one only P4 system do any TF! According to undoc.txt:- You can limit how far the program tries to factor a number. This feature should not be used with the Primenet server., which implies that something bad will happen if you do. Umm. I guess there is a possibility that PrimeNet might get confused about whether an assignment is completed (as far as the system running it is going to go). Suggestion: the TF savefile should be modified to contain an internal consistency check (say the MD5 checksum of the decimal expansion of the current factoring position) so that cheating by editing the savefile, causing jumping past a large range of possible factors, would be made a great deal more difficult. Easily cracked. Why not just encrypt it? True. But the problem with encryption is that it has to be decrypted - if the client knows how to do that ( it has to, if the save file is to be any use at all) then a cheat can dig out the code somehow. One thing that could be done is to write an extra hidden save file (or store a registry key) containing some value computed from the save file contents, so that if the save file was manually changed there would be a clash the client would know something odd had happened. Another trick (which I actually used in a now-obsolete anti-tamper system) is to take the time the file is opened for writing (in unix seconds) xor that into part of the file data. When checking the file, read the file creation date from the directory, xor into the data, if the file checksum fails increment the creation date try again - at most 10 times, since the file creation date (stored in the directory) shouldn't disagree with the system clock read by your program just before it called the file open routine by very much. This works pretty well because few people will twig what you're doing (even if you document it!) even fewer will manage to frig the checksum properly. The idea here is to make successful cheating not worth the effort. There's no way it's going to be possible to stamp it out altogether. Personally I'm more concerned about the possibility of cheating your way up the PrimeNet LL testing league table. The obvious way to do this is to start a test, stop manually after a minute or two, edit the iteration number to a few less than the exponent restart ... lo behold, you _could_ complete LL tests on _any_ exponent in about five minutes, even on a P90 system. The fact that the residuals would all be wrong is irrelevant since PrimeNet doesn't penalise bad results; in any case, you'd probably get away with it until DC started to catch up with you. An internal consistency check would make this a lot harder to do. MD5 is pretty good (though not perfect) as there is no simple way to fudge it; the compute effort involved in frigging a file to achieve a specified MD5 sum is several orders of magnitude greater than that required to LL test a 10 million digit exponent, so it's simply not worth trying. Regards Brian Beesley _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: TF - an easy way to cheat
Anyone receiving a TF task could edit the worktodo.ini from Factor=20.abc.def,59 to Factor=20.abc.def,65 He would receive approx. twice the credit the effort is worth. Ofcourse nobody would do this, as we are all volunteers! Or could somebody some day be tempted to raise his rank using this method? Does GIMPS hold some log for TF's done by which account? If so could this log please be open? Would this cheat be trapped later by P-1 or does P-1 trust earlier work so factors below say 67-bits are not considered? The above questions are _not_ asked because I intend to use the method. :-/ I think it would miscredit GIMPS as we trust the results of GIMPS. And I would be disappointed if I learned that an LL I did could have been solved far earlier - and using less effort. br tsc _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
