How do we prevent miraculously true DC results from manual submit?

[ET_]

Originally Posted by Xyzzy

Madpoo wouldn't agree with you. His triple and quadruple checks would grow exponentially

[retina]

There is currently no problem. So there is currently no need to change anything.

But if for some reason you really want to worry yourself about theoretical problems that don't yet exist then don't display any residue until they are matched.

[GP2]

Originally Posted by retina

There is currently no problem. So there is currently no need to change anything.

But if for some reason you really want to worry yourself about theoretical problems that don't yet exist then don't display any residue until they are matched.

Originally Posted by retina

I haven't run updates now since 2006. So I disagree that they are necessary. But I agree that a lot a people think they are necessary.

*

Dude, I dunno. Maybe between extreme paranoia and extreme blitheness there might be a happy medium.

[Madpoo]

Originally Posted by ET_

Madpoo wouldn't agree with you. His triple and quadruple checks would grow exponentially

LOL. I do notice that when I post new lists of "strategic double checks", the triple checks I look for later do indeed climb in frequency.

Which is a good thing... it means we're still doing a good job of weeding out the "probably bad" results and doing proactive checks.

Which, to stay on topic, would be a factor in this discussion.

Let's say some user starts submitting results trying to match the first time check. Randomly, they'd be expected to match on the first try only one out of 256 times. That means 255 out of 256 times they're going to generate at least one mismatch that would start to show up in my triple-checking project.

And on top of that, the machine turning in all of these bad results is going to show up in my queries of "really bad machines" and I'd like to think it would be so obvious it would stick out like a turd in a punch bowl.

And that's even if only one extra "bad" result showed up per exponent. In reality there would be, on average, something like 127-128 new bad results flooding in before a match was found (anywhere from 1-255 extra bad results).

That kind of thing would not only draw the attention of myself, but there are others who look at the daily results coming in and something like that even on a single exponent would be very obvious.

It wouldn't even matter if they tried creating different accounts to submit each result or different CPUs (manual results all technically come from a single CPU account per user). There's really no good way to try and mask an attempt like that where it would somehow fly under the radar.

It would be simple enough to mask three or four of the sixteen hex digits of unverified residues, rather than just two. This would be a trivial change, maybe after a short announced transition to allow automated scripts to adjust, if necessary.

Probably having only the last two hex digits masked is a legacy from the days when we were still verifying old pre-GIMPS results that had only four or five hex digit residues rather than the current sixteen. But all of those have long since been double checked to the full sixteen hex digits.

Masking 2 hexits is probably from what you said... the earliest of the earliest results were legacy code/mainframe class systems that just had 4 hexit residues, so masking more than a couple meant you may as well mask the whole thing.

Those early results are certainly all double checked (and triple or quad checked, many by yours truly).

If it became a problem (or if we wanted to) I guess we could mask more, like 4+ hexits, or simply, as suggested, not show residues at all until a match is made.

I'm not entirely sure what all of the arguments are in favor of showing masked partial residues... I'm sure it comes in handy for troubleshooting new code when you want to see if a mismatch could be due to a LSB issue of some kind, or if you see a residue of all 0's, you could guess the masked part is probably 0x02 so it got into that error loop. Or in the case of Xolotl's weird results, it has a zero residue but checks in as "composite" in some magical way.

There are a few different places in the site code responsible for masking residues. In theory it wouldn't take too much time to find all of those and tell it to mask 2 bytes. Whether or not to bother is another question since the risk at this point seems theoretical. If it became real, it wouldn't be too much trouble to address, even if it meant masking all 8 bytes of the partial residue or hiding it altogether.

[preda]

I think discussing "how much masking" is barking up the wrong tree. IMO the real danger is one [evil] person with two accounts, doing both first-time LL and double checks on the same exponents -- and he'd have no issue with masking at all because he submitted the full residue in the first place.

[science_man_88]

Originally Posted by preda

I think discussing "how much masking" is barking up the wrong tree. IMO the real danger is one [evil] person with two accounts, doing both first-time LL and double checks on the same exponents -- and he'd have no issue with masking at all because he submitted the full residue in the first place.

if actually done on separate hardware this isn't so much a problem in theory ( if done with the same hardware they can check an identifier probably). Also if it checks if it's assigned it would have to be assigned to both accounts first before this becomes the problem I think. not that I run software I mostly just play around in PARI/GP and annoy people here.

[preda]

Well, to submit fake results just to ruin things he'd need mostly no hardware at all, I think.

[science_man_88]

Originally Posted by preda

Well, to submit fake results just to ruin things he'd need mostly no hardware at all, I think.

assumes it doesn't need to be assigned to be submitted.

[chris2be8]

Originally Posted by preda

Well, to submit fake results just to ruin things he'd need mostly no hardware at all, I think.

To get away with that he needs to ensure all his first time checks are double checked by his second account. So checking for pairs of accounts that double check each other and triple checking a sample should catch that.

Chris

[GP2]

Originally Posted by chris2be8

To get away with that he needs to ensure all his first time checks are double checked by his second account. So checking for pairs of accounts that double check each other and triple checking a sample should catch that.

Chris

Who needs an account? Just submit your results under someone else's name. I track all of my assignments and would catch this, but probably not everyone does.

[GP2]

Originally Posted by GP2

Who needs an account? Just submit your results under someone else's name. I track all of my assignments and would catch this, but probably not everyone does.

Also, is there any restriction on choosing a public name in PrimeNet, or can you choose a name that matches someone else's? If I see a result returned by "MadPoo" I'll trust it more than Joe Random.

It's certainly possible to do so in a case-insensitive way, for instance 42794813 was tested by "Rick" and "rick". I suppose these are two different people and not a self-verification...