Residue not matching due to masked bits
 

I just did a successful double-check of 33238477 with residue D12F51397BCA233C. There is also a bad result for this exponent with residue D12F51397BCA23__ (by Daniel Weijand, computer name C7364A0E9). It is obvious that this result is not really a bad result, but somehow the masked bits made it into the database.

I looked in some old status files that I have kept, and the result of the first test looks like[CODE]33238477,S67532,C7364A0E9,W?,[/CODE] in the hrf3 file. In cleared.txt it was reported as [CODE]33238477 69 0xD12F51397BCA23__ 01-Sep-03 14:16 S67532 C7364A0E9[/CODE] The double check was done right after that with hrf3 line[CODE]33238477,S01167,laptop,WZ1,00000000[/CODE] and [CODE]33238477 69 D 0xD12F51397BCA23__ 11-Nov-03 03:17 DL laptop[/CODE] in cleared.txt.

Does anybody know what has happened?

Well, from my fuzzy ancient memories....

A v4 server hiccup, the details of which I've long since forgotten about, caused some LL results to be lost -- only recoverable from a report that showed the masked bottom 8 bits.

At the time, I figured it was best to add the results to the database without valid bottom bits so that the exponents would not be handed out as first-time tests and the user received proper CPU credit.

In looking the last pre-v5 database, it looks like there were 4 such cases: 18050569,19857121,33238477,33254747