skipped bit levels

[dbaugh]

I do TF well beyond normal depth because I find it convenient and interesting. I do the TF work on a GPU and keep the CPU busy with P-1 and ECM. If the CPU finds a factor that is not too big, I will continue the TF work on that exponent to even higher levels to make sure that I have found all the factors up to that limit. I do this for the sake of completeness. An exponent status without gaps pleases me. This makes me a red flag machine.

I think the real red flag is a 106 bit factor claiming to have been found by TF. Or, someone who misses an unreasonable number of factors in bit ranges they claim to have searched. I am a fan of the honor system but, with a group in the tens of thousands open to all comers in the world, it may not be sufficient. Isn't there some way to verify that the work submitted was actually performed? Bitcoin is not credited to people who merely claim to have mined.

How well do the statistics match the theory?

[bloodIce]

With a good system to track the gaps and resending only this work for TF will mean that the problem will not exist in a day or two :-). By the way, only gaps above 60 bits should be considered, because TJAOI already did (or soon will do) the dirty work of double checking everything below 60. Not that TF54-55 is a problem nowadays, but it is unlikely to produce a result (if TJAOI is systematic). That question was asked somewhere, but how much work will be to re-TF everything to the current bit-levels? And only 1/1000 000 (gaps) of it?

P.S.: Another sieve is to check for gaps only in non-DC exponents... this will reduce the work a lot.

[Madpoo]

Originally Posted by dbaugh

If a person was corrupt and mad at GIMPS couldn't they have two IDs and fake enter LL and DC for a bunch of exponents and screw up the search for the next prime? There has to be some protection against this and so fake TF could be similarly protected against.

There are a few things that I've kept an eye on like two LL results coming from different machines but suspiciously close to each other, temporally. If it seemed fishy I ran a triple-check. There aren't many of those left and the ones that are were all older ones where the dates are only rounded to the nearest week or two.

Otherwise, someone would really have to be trying to game things and be a <insert bad word here> about it to fake the same residues with a different shift-count and coming from different accounts, all while keeping the secure checksum thing valid.

In the meanwhile, we do keep an eye on things, and there are a few other avenues for potential monkey business that I try to look out for, and I'm sure some of you have keen eyes as well and tend to notice "strange things".

[Madpoo]

Originally Posted by dbaugh

Isn't there some way to verify that the work submitted was actually performed? Bitcoin is not credited to people who merely claim to have mined.

Bitcoin miners (if I understand it, which is a big assumption) get "credit" when they "discover a block", which is provable.

If we applied that to GIMPS for TF work, you would only get credit for finding factors, and mere attempts would be credit-less.

Actually that wouldn't be a bad idea... if we figure the average is one factor for every 70 attempts, then maybe we make "factor found" worth 70x more credit, and no credit at all for "no factor found" TF results. Some users who get a string of unusually good or bad luck will have skewed results, but if they keep at it long enough, the law of averages kicks in.

Eliminate any incentive to cheat and then all you're left with are the true <insert bad word here>. Then you'd just have to worry about the "I meant well" people who oh-so-helpfully submit bogus "no factor between X and Y" when they found an x-bit factor by P-1.

Those people are simply clueless and when we see them doing that we really should be taking them to task. The ones we've caught previously, maybe they don't frequent the forum but George or someone might want to email them and ask them not to do that, it pollutes the data stream. And maybe they'd stop anyway if they weren't getting horribly large amounts of factoring credit that they never actually did... perhaps their motives aren't entirely misguided altruism.

[chalsall]

Originally Posted by Madpoo

Actually that wouldn't be a bad idea... if we figure the average is one factor for every 70 attempts, then maybe we make "factor found" worth 70x more credit, and no credit at all for "no factor found" TF results.

Actually, I think that would be a really bad idea.

As an example, a GPU72 user was initially discouraged because he hadn't found a factor after his first (something like) 200 attempts. This same user, after about a thousand attempts, is almost exactly "on the money".

I also watch out for hmmmm'ness in the TF space, and have spent a lot of time and money double checking the TF'ing of those who are "unlucky".

I have never once caught anyone cheating.

[S485122]

If missing bit levels are really important to someone, let them report them. They can be incorporated in the database. But if those "skipped" bit levels are so important to them, the satisfaction of having them filled in should be enough : no credit, unless a factor is found.

Jacob

[dbaugh]

It is heartening to know that there are multiple efforts to keep the data pure and very little monkey business is being found.

I am OK with S485122's suggestion if the gap was created by an out of order TF factor found. Once a factor is found why are ECM and P-1 results still accepted but the next bit level TF not? Will exponent statuses reflect TJAOI work or is it just to be assumed up to some stated exponent size?

[retina]

So all this talk about credit whores is moot right? There is so little evidence that it occurs that I think it can be ignored. Given that, then there is no reason to even have all this discussion about how much credit to give for certain work units. Just give all the work credit and forget about trying to make special rules "just in case" someone is trying to cheat the system. Like I mentioned above, it costs nothing to give credit, and it has no real world value also, so don't worry about.

And if later it is discovered someone did cheat then just remove the credit for that person. It is just a number and it can be both given and taken away. No big deal.

[Madpoo]

Originally Posted by retina

So all this talk about credit whores is moot right? There is so little evidence that it occurs that I think it can be ignored. Given that, then there is no reason to even have all this discussion about how much credit to give for certain work units. Just give all the work credit and forget about trying to make special rules "just in case" someone is trying to cheat the system. Like I mentioned above, it costs nothing to give credit, and it has no real world value also, so don't worry about.

And if later it is discovered someone did cheat then just remove the credit for that person. It is just a number and it can be both given and taken away. No big deal.

Well, it's not up to me, but I guess if I *had* to make a decision on my own given the current discussion, I'd do this:
- Allow results for lower than max TF bit levels, but give no credit

The people most likely to report those things are not interested in credit, they're doing it to make sure any possible gaps are filled in... I'll call them the spacklers. LOL Smoothing out the cracks.

[kladner]

Originally Posted by dbaugh

It is heartening to know that there are multiple efforts to keep the data pure and very little monkey business is being found.

I am OK with S485122's suggestion if the gap was created by an out of order TF factor found. Once a factor is found why are ECM and P-1 results still accepted but the next bit level TF not? Will exponent statuses reflect TJAOI work or is it just to be assumed up to some stated exponent size?

There are some very sharp-eyed people here, who have a much greater grasp of the systems and maths than I. There are many ways to display the PrimeNet data. I get the impression that different people are attracted to different means of analysis.

There are frequent discussions of whether or not a particular pattern for a user is cheating, or just eccentric interests in testing and reporting.

I have learned a lot from these conversations.

[Mark Rose]

I found a bunch of exponents with incongruent entries in their history versus their TF bit levels:

55731157 is factored to 72 but: no factor from 2^72 to 2^73
55731289 is factored to 72 but: no factor from 2^72 to 2^73
74412967 is factored to 73 but: no factor from 2^73 to 2^74
75281351 is factored to 72 but: no factor from 2^72 to 2^73
77251633 is factored to 75 but: no factor from 2^75 to 2^76
79864727 is factored to 71 but: no factor from 2^71 to 2^72
80378209 is factored to 71 but: no factor from 2^71 to 2^72
80381629 is factored to 71 but: no factor from 2^72 to 2^73
80384219 is factored to 71 but: no factor from 2^71 to 2^72
80384363 is factored to 71 but: no factor from 2^71 to 2^72
80385091 is factored to 71 but: no factor from 2^72 to 2^73
81456223 is factored to 72 but: no factor from 2^72 to 2^73
81604043 is factored to 72 but: no factor from 2^72 to 2^73
81604799 is factored to 71 but: no factor from 2^71 to 2^72
81672587 is factored to 71 but: no factor from 2^71 to 2^72
81680387 is factored to 71 but: no factor from 2^71 to 2^72
81683083 is factored to 71 but: no factor from 2^71 to 2^72
82226083 is factored to 72 but: no factor from 2^72 to 2^73
82439473 is factored to 71 but: no factor from 2^76 to 2^77
82526453 is factored to 72 but: no factor from 2^72 to 2^73
83152723 is factored to 71 but: no factor from 2^71 to 2^72
85293011 is factored to 71 but: no factor from 2^71 to 2^72
86526173 is factored to 72 but: no factor from 2^72 to 2^73
87421849 is factored to 72 but: no factor from 2^72 to 2^73
87475813 is factored to 73 but: no factor from 2^73 to 2^74
87901921 is factored to 71 but: no factor from 2^71 to 2^72
89030969 is factored to 71 but: no factor from 2^72 to 2^73
89337019 is factored to 71 but: no factor from 2^71 to 2^72
89549671 is factored to 72 but: no factor from 2^72 to 2^73
91540409 is factored to 71 but: no factor from 2^71 to 2^72
91540609 is factored to 71 but: no factor from 2^71 to 2^72
93682709 is factored to 71 but: no factor from 2^71 to 2^72
94086557 is factored to 71 but: no factor from 2^71 to 2^72
95487307 is factored to 71 but: no factor from 2^71 to 2^72
96001991 is factored to 73 but: no factor from 2^66 to 2^79
99201469 is factored to 71 but: no factor from 2^71 to 2^72
99300569 is factored to 71 but: no factor from 2^71 to 2^72
99443723 is factored to 71 but: no factor from 2^71 to 2^72
101344697 is factored to 72 but: no factor from 2^74 to 2^75
101345863 is factored to 72 but: no factor from 2^72 to 2^73
102749963 is factored to 71 but: no factor from 2^71 to 2^72