DC mismatches

[moebius]

25891057
26830123

46678811
46738091
47842481
49052579
49054861
49997309
50217353
50217379
50636153
51936263
51936497

[Dubslow]

I don't think we need to include LL-wavefront exponents; by the time the DC wavefront gets there, CUDALucas will almost guaranteed have the bit-shift built into it.

[LaurV]

Originally Posted by Dubslow

I don't think we need to include LL-wavefront exponents; by the time the DC wavefront gets there, CUDALucas will almost guaranteed have the bit-shift built into it.

And if it will not have the bitshift? Better safe then sorry. If the tester want to include the LL-Front, why not? (in this case it in first time test, do no residue available to check, therefore, if you want, then you have to include all "first time" LL's you do).

In fact the problem is not only the bitshift, but also the manual reporting procedure, with no "security key". One could easy use two (or more, to avoid patterning) user names in one (or more, to avoid same IP or comp ID) computers, run ONE test only and report it more then once. No matter what we do, George will never agree to accept DC clearance by third parties only, without a bit of P95 security into it, unless the third party implements all the stuff as bit shift, assignment key, security key, same format as P95. So better to have all tests done with CL (DC and LL) written down somewhere, for the time when the wave will advance. Right now is a pain in the ass to tell them apart (CL or P95) on the DB.

[Dubslow]

Size of the list will be much bigger then.