Quote:
Originally posted by NickGlover
Very large factors are truncated in the Primenet reports which is why the 102 and 103 bit factors appear bogus. The actual factors found are actually larger than 102 and 103 bits, and the correct factors do get to George, even if they don't show up on Primenet correctly.

Hmmmm, you're quite right.
cleared.txt has the following:
Code:
16091291 103 F 7362770625422642419324076409959 05Dec02 04:11 S24590 4
18965599 103 F 8602653675602192712514732427431 30Apr03 04:46 S58485 CHERRY
33475447 103 F 7621901790064563660031276374525 14Aug03 17:44 eipi ulka
Whereas the actual factors are
16091291,117362770625422642419324076409959
18965599,34488602653675602192712514732427431
33475447,7621901790064563660031276374525079
(1st = 2 digits truncated at the start)
(2nd = 4 digits truncated at the start)
(3nd = 3 digits truncated at the end)
Now, if we were missing the above actual factors, we could still reconstruct them based on the cleared.txt values. This can be done by running a script that adds every combination of up to 6 digits at the start or the end of the truncated factor, and then checking each new value for (2^p  1) mod f == 0 using an extendedprecision arithmetic package like libgmp on Linux. This takes about a minute or so on a 2.8 GHz P4.
However, I was unable to reconstruct the factors (if they actually exist) for the original exponents in question:
15370879
15729167
I tried every combination of up to extra 6 digits at the start or up to 6 at the end, without any luck.
However, there's also some weird stuff in cleared.txt. Check this out:
Code:
8276539 103 DF 7411192628700266363789140779170 18Nov02 00:48 Team_Prime_Rib Tasuke18
17699497 103 F 8254656556609760068242738155742 26Mar03 08:12 Team_Prime_Rib KL_MLChan
18129493 103 F 8754500160125057908417949485956 24Feb03 07:26 curtisc wde310009
What's wrong with this picture?
1) These are all bogus factors.
2) Even assuming they were truncated by up to 6 digits at the start or up to 6 digits at the end, they're still bogus.
3) Much smaller known factors exist:
8276539,67600209174876814543
17699497,73630130820677243353
18129493,303330458703290742127
There are a number of similar examples, I haven't yet investigated how many, with many different users.
I singled out a couple of Team_Prime_Rib exponents: maybe you guys can contact those folks and ask them what's in their results.txt.
Maybe we can figure out why huge bogus factors are getting sent to the server...
And I'm guessing that
15370879
15729167
are also bogus in the same way as the above (with the only difference being, for those two cases, we don't have any muchsmaller known factors, in fact no known factors at all).
Quote:
Also, the server will reject any factors that don't pass a simple verification calculation. That's how we know that no bad factors have ever caused us to miss a prime.

Actually, we also can do the (2^p  1) mod f == 0 test on the entire factors database. With a 2.8 GHz P4, the entire database of 2,651,013 factors can be verified in a couple of minutes. I've done this, and there are indeed no bad factors.