[quote=retina;140751]Yes you are right about the sparseness, but I think it really doesn't matter since the lack of a fake residue[1] doesn't mean much. Indeed the lack of a fake residue would give less clues as to where/when the genuine exponent is.

[1] Here by "fake residue" I mean the residue that we can all recognise with the known algorithm. This does not include the as yet unknown algorithm that is used for the genuine exponent.[/quote]
True, but if they wanted to give us no hints, as that would do with M46 on, why would they bother giving us any hints now?

Let's think as if we were writing the PrimeNet database (and its front-end) for the first time. The submissions (from external world) and queries (e.g. primenet_report . pl ? username ... ) will be wildly asynchronous and fairly many. So you want to keep transactions atomic: in simple words when submission "UID: Batman/batmobil_microwave, M36213629 is not prime. Res64: 9352A4330EB824__. Wd1: DB2B945D,30277304,00000000" (or put "Res64: 0000000000000000" there) comes in - there's no [B]other[/B] transaction in hand. There's nothing else to spoil or swap. [SIZE=1](of course it can be triggered, but it's uglier to debug and hard to maintain - you can break it when you change something else in the other corner of the code. Ugly.)[/SIZE]

My guess is - the guts of the database are simply honest. It keeps everything plain. (It is possible to generate a random residue right at the moment of the insert transaction, but then you will have made your own life harder and either you have to set some secret flag to "1" and "0" for all others - and waste some space for an extra column, _or_ you can create a fake residue by a certain rule and you will have false positives, too, because Res64 can have any value! unless, again, there is redundancy in it, like in a credit card number. The possible digressions in these parentheses are of course infinite - we can patch and patch-a-patch, and patch again, on many levels...)

My second guess is that it is the presentation layer (the script that generates summary.txt, cleared.txt, etc file) that cheats. (Remember, this is our only "window" into the database.) It runs only once an hour, so at least personally I would do it right there. If that is so, at the time of generation it has access to all the data from the last synchro (with another bigger table); or as a result of optimizations - there could be three data areas - the really big tables, the last month tables and the last hour tables. The last two would be then synchronized every hour. The first two would be merged every month.

In short, I'd expect the true thing to be within the last hour ([I]anywhere[/I] in it). Less likely, it could be anywhere in the cleared.txt but [I]then[/I] it [I]can[/I] be sleuthed by those who save every report.

My 2 roubles.

[SIZE=1]P.S. I re-read the message and it may be confusing to those who use the prime digit calculator. My apologies. It could be dumbed down more, but life is too short (and day job trumpets are calling for another meaningless battle).[/SIZE]

--Serge

:goodposting:

And the easy thing is that, when the report is run, the "Unverified Prime" flag is reported early on and ready to muddy the residues.

[quote=Batalov;140786]Let's think as if we were writing the PrimeNet database (and its front-end) for the first time.[/quote]Good idea, Serge.

[quote]when submission "UID: Batman/batmobil_microwave[/quote]:cool:[quote], M36213629 is not prime. Res64: 9352A4330EB824__. Wd1: DB2B945D,30277304,00000000" (or put "Res64: 0000000000000000" there) comes in - there's no [B]other[/B] transaction in hand. There's nothing else to spoil or swap.[/quote]I'm not sure whether you're saying that the report processor has no previous report cached "right there", or it has no immediate access to existing database records, or that this is the first-ever GIMPS report (so that no other database record exists).

That third case wouldn't be relevant because when starting up GIMPS, George gathered up all the earlier databases of L-L residues to initialize the GIMPS database. That is, when hypothetically writing the database interface or front-end, we can safely assume that the database already has records of some previous residues from L-L tests of both composite and prime Mersennes.

=> BTW, keep in mind the possibility that there is a secondary database for the Mersenne primes, with more information stored about each than is stored for a composite. (A zero residue in the main database could serve as flag telling the presentation software to go to the secondary database in those cases.) This extra information could include data added after original report receipt, such as the fake residue, details of discovery and discoverer(s), news releases ...

[quote]My guess is - the guts of the database are simply honest. It keeps everything plain.[/quote]I agree.

[quote](It is possible to generate a random residue right at the moment of the insert transaction, but then you will have made your own life harder and < snip > we can patch and patch-a-patch, and patch again, on many levels...)[/quote]I agree that that would be the wrong way to do it.

It'd be easier to have a secondary database for just the primes, where one could store the however-generated fake residues among other things.

The report processor could spawn a prime-processing task (or call a subroutine) whenever it received a zero-residue report. That task/subroutine would initialize the new entry in the secondary database, including fake residue generation. (Also, send out the e-mail notifications ...)

[quote]My second guess is that it is the presentation layer (the script that generates summary.txt, cleared.txt, etc file) that cheats. (Remember, this is our only "window" into the database.)[/quote]"Cheat"? Oh, no... We have simple honesty in all things, not only the database ("the guts of the database are simply honest")! It's just that the honest presentation layer simply uses the honest secondary database in addition to the honest primary database. :smile:

[QUOTE=ixfd64;140686]To make sleuthing easier, I've arranged the results returned between 7:00 p.m. and 8:00 p.m. UTC on August 23, 2008:

[quote][i]37425887 68 0x9B10891A72B405__ 23-Aug-08 7:02 BranMuffin ROTV-O4
37946213 69 0x901FF5AA04168E__ 23-Aug-08 7:19 S611352 p4raid
43096799 69 0x32E28ECEC2C31B__ 23-Aug-08 7:21 TeamRessler 1062315
38859463 69 0x5840B65CA7CB7B__ 23-Aug-08 7:23 curtisc JCKL-cce41L
43411699 69 0x7C0112FE295ECD__ 23-Aug-08 7:25 salfter office1
36705287 70 0xDDA8BEB967041D__ 23-Aug-08 7:32 dmazh dm2
42206137 69 0x0A0EEC17151DAC__ 23-Aug-08 7:33 drrocket MIS5PC
43112609 69 0x8691696D2BDA50__ 23-Aug-08 7:33 UclaMath C20E3341C
37763179 70 0xB141C151483C99__ 23-Aug-08 7:34 curtisc wcm128--03L
40896127 69 0x4F9CCA10FDF131__ 23-Aug-08 7:35 fcg619 C1391
28829407 69 0x849E58408C92DE__ 23-Aug-08 7:41 hagenbuchner XENserv1
42801739 69 0xF6DDB517B9A4C6__ 23-Aug-08 7:44 DingoDog starfury
42760397 70 0xA6090C299C0678__ 23-Aug-08 7:46 curtisc JCKL-ccd62L
[B]32428427 69 0xB6C80137FEDB7E__ 23-Aug-08 7:49 suuuncon SPDELL[/B]
41935241 69 0xEDB167FA1DBB31__ 23-Aug-08 7:53 S00039 Cinebox_0
41959849 69 0xD689BE98B86C77__ 23-Aug-08 7:53 curtisc grn206--11l
42781927 69 0x8613884B69237A__ 23-Aug-08 7:56 jmoseley Vader
42796219 69 0x4F4C53A0908A5D__ 23-Aug-08 7:59 DingoDog starfury[/i][/quote]

Random fun with p-1:

37425886 = 2 * 18712943
37946212 = 2^2 * 1237 * 7669
43096798 = 2 * 21548399
38859462 = 2 * 3^2 * 2158859
43411698 = 2 * 3^2 * 11 * 219251
36705286 = 2 * 23 * 61 * 103 * 127
42206136 = 2^3 * 3 * 7 * 29 * 8663
43112608 = 2^5 * 7 * 11 * 17497
37763178 = 2 * 3 * 6293863
40896126 = 2 * 3^2 * 599 * 3793
28829406 = 2 * 3 * 59 * 81439
42801738 = 2 * 3 * 7 * 29 * 35141
42760396 = 2^2 * 7 * 1527157
32428426 = 2 * 263 * 61651
41935240 = 2^3 * 5 * 311 * 3371
41959848 = 2^3 * 3 * 7 * 379 * 659
42781926 = 2 * 3 * 11 * 648211
42796218 = 2 * 3 * 7132703

Nothing to see here, folks, let's just keep the line moving smoothly along...

[QUOTE=jinydu;140731]
To other sleuthers: At the risk of sounding repetitive... The residue given to the real M44 was 663C8660956654. How do you think this was generated?

If it was not generated randomly, this could open up a new line of attack...[/QUOTE]

In binary, the fake residue for the real M44 is 1100000100110101111000001110011000111101110. 32582657 in binary is 1111100010010110000000001. I don't see anything...

[quote=ewmayer;140803]To make sleuthing easier, I've arranged the results returned between 7:00 p.m. and 8:00 p.m. UTC on August 23, 2008:



Random fun with p-1:

37425886 = 2 * 18712943
37946212 = 2^2 * 1237 * 7669
43096798 = 2 * 21548399
38859462 = 2 * 3^2 * 2158859
43411698 = 2 * 3^2 * 11 * 219251
36705286 = 2 * 23 * 61 * 103 * 127
42206136 = 2^3 * 3 * 7 * 29 * 8663
43112608 = 2^5 * 7 * 11 * 17497
37763178 = 2 * 3 * 6293863
40896126 = 2 * 3^2 * 599 * 3793
28829406 = 2 * 3 * 59 * 81439
42801738 = 2 * 3 * 7 * 29 * 35141
42760396 = 2^2 * 7 * 1527157
32428426 = 2 * 263 * 61651
41935240 = 2^3 * 5 * 311 * 3371
41959848 = 2^3 * 3 * 7 * 379 * 659
42781926 = 2 * 3 * 11 * 648211
42796218 = 2 * 3 * 7132703

Nothing to see here, folks, let's just keep the line moving smoothly along...[/quote]
What the heck? Aren't all Mersenne exponents supposed to be prime?

He's looking at p-1, not p.

Some time ago we noticed that for [I]p[/I] s.t. M[I]p[/I] is prime, [I]p[/I]-1 has slightly more small prime factors than primes chosen uniformly at random from a large interval of primes. But with only 44 data points, of which the smallest ones must be excluded to avoid bias, this statistic isn't very meaningful.

Alex

[quote=akruppa;140824]Some time ago we noticed that for [I]p[/I] s.t. M[I]p[/I] is prime, [I]p[/I]-1 has slightly more small prime factors than primes chosen uniformly at random from a large interval of primes. But with only 44 data points, of which the smallest ones must be excluded to avoid bias, this statistic isn't very meaningful.

Alex[/quote]That's interesting. I didn't know that.
Some from the list that catch my eye:
[quote=ewmayer;140803]43411698 = 2 * 3^2 * 11 * 219251
36705286 = 2 * 23 * 61 * 103 * 127
42206136 = 2^3 * 3 * 7 * 29 * 8663
42801738 = 2 * 3 * 7 * 29 * 35141
41959848 = 2^3 * 3 * 7 * 379 * 659
42781926 = 2 * 3 * 11 * 648211[/quote]These would be more likely, then.
My guess (encrypted with my oh-so-hard encryption as usual) is B0081637. Multiple things seem to point to this:
1. 32428427, the one that had the known residue algorithm applied, was the smallest first-time LL after this guess (like my suggestion elsewhere in this thread would suggest is what it applies the known algorithm to).
2. This guess's p-1 is rather smooth (sorry if smooth is more well-defined than I'm using it, but I think my point is across, i.e. it's on the list of p-1 factors that catched my eye as having many small prime factors).
3. It's well into the 10M digit range, which from the time estimates is where I'd assume M45 is.
4. (minor note: it is a first-time LL)

Now over 55% complete. :spot::spot::spot::spot::spot: