Poaching

[cheesehead]

Sayyy ...

If Primenet no longer publicly reported days run and date assigned or those other four fields, and if poaching really did go way down, then we wouldn't need such stringent time limits on assignments. Like, 200 or 300 days instead of only 100 days. That would cut off fewer "slow" participants.

Right?

[garo]

I'd beg to differ here. I DO NOT think that the elimination of these items from the reports will eliminate cheating. Not at least until it is coupled by the three very good suggestions made by George earlier in this thread and a new version of the Primenet server. All this will do is - make poaching completely dumb and remove only "intelligent" poaching!! Let me state here that I am against any form of poaching but some are worse than others.

Let me explain -
Someone either on the mailing list or in this forum explained a while back - I think it was trif but I may be wrong - that there are three different kinds of poaching of trailing edge exponents - since that is the kind of exponent that gets poached most often. Also, I exclude "accidental poaching" when an exponent expires and is reassigned and then the original assignee turns in a result.

1) The poacher looks for exponents that are about to expire soon and completes them a day or two before expiry. Arguably the poacher want to prevent an exponent that would have most likely expired - to fall into the hands of a newbie or someone else who does not check their machines/exponents and then to wait till it is completed in 2-3 months. The chances of the original assignee returning a result in the 3-4 days right before the exponent is about to expire, or even to update on the server are pretty slim so one can argue that this method does not scare a lot of participants away.

2) In method two, the poacher does not wait for an exponent about to expire but instead targets exponent that have not been updated for 30 days or more or possibly have not been started work on - this information is obtained by iterations complete - or in some cases show 100 or more days still left for completion. Very often these kinds of assignees are newbies who get a trailing edge exponent by accident and then forget all about it, turn the machine off or realise that they are not willing to wait 10 days for an exponent to finish and switch projects without uninstalling/quitting GIMPS. This sort of poaching probably scares away more participants because sometime legitimate participant do not update in 30 days while the exponent in being actively worked on. This is particularly true of Mlucas and Glucas participants since their clients do not contact Primenet and thus Primenet cannot record the iterations complete information. Moreover, sometimes if a Prime95 participant has some other application running at the same time as Prime95, the latter recomputes the days to finish on the basis of the amount of CPU Prime95 is getting and a very incorrect stimate of days to finish can appear on Primenet, incorrectly catching a type-2 poachers attention.

3) the third and the worst method is when the poacher poaches indiscriminately without any regard to whether the exponent is about to finish, is being actively checked in or not etc. Malfoy is the latest example in this trend though his case is particularly egregious, in the past other offenders of this type have been known to exist.
Edit: ops: I put some names down here somewhat rashly without checking if these people had poached by type1, type2 or type3. My apologies to them. The names that were here were chiefly of people who were type1 and type2 poachers and not type3 poachers.

I'd also like to ask you - do you really think that Malfoy - when he sees three exponents blocking say M#38 - will not poach them just because there are no dates on them?? I DONT think so!

Removing the information you mentioned will make all poaching type-3 poaching instead of some type1 , type2 and type3 that we currently see. And no type3 poacher will really care if we remove the info as you suggest!

[cheesehead]

Thank you for your reply, garo -- especially listing the 3 poaching types.

Originally Posted by garo

I'd beg to differ here. I DO NOT think that the elimination of these items from the reports will eliminate cheating.

I'm not claiming my suggestion would completely stop poaching.

What I claim is that it denies poachers the information that I think they currently use to select straggling assignments (i.e., type-1 or type-2) to poach. It seems to me that elimination of those public report items would prevent, or at least make much more difficult, the type-1 and type-2 poaching, and thus significantly reduce the frequency of poaching.

Not at least until it is coupled by the three very good suggestions made by George earlier in this thread and a new version of the Primenet server.

Okay. Maybe we'll have to add automatic expiration and reassignment to Primenet in order to fully achieve what I think my suggestion could achieve.

But I still think we'd get partial benefits by restricting the public reporting of the fields I listed, now -- even without any Primenet changes.

All this will do is - make poaching completely dumb and remove only "intelligent" poaching!!

I'm not convinced that there is any significant amount of dumb (i.e., type-3, I think you mean) poaching going on. I think that all current poaching is "intelligent".

See my later comments about type-3.

I exclude "accidental poaching" when an exponent expires and is reassigned and then the original assignee turns in a result.

I agree. I was referring only to deliberate poaching, also.

1) The poacher looks for exponents that are about to expire soon and completes them a day or two before expiry.

So, eliminating days-to-expire (and maybe other fields, if one can derive days-to-expire from them) from the public report would deny type-1 poachers the information they need to select targets.

2) In method two, the poacher does not wait for an exponent about to expire but instead targets exponent that have not been updated for 30 days or more or possibly have not been started work on - this information is obtained by iterations complete - or in some cases show 100 or more days still left for completion.

So, eliminating current iteration, days-to-go, and date-updated (and maybe other fields, if one can derive any of those three from the others) from the public report would deny type-2 poachers the information they need to select targets.

Very often these kinds of assignees are newbies who get a trailing edge exponent by accident and then forget all about it, turn the machine off or realise that they are not willing to wait 10 days for an exponent to finish and switch projects without uninstalling/quitting GIMPS.

So if we don't report any of the data fields which a type-2 poacher needs in order to determine which assignments look like they're abandoned, a would-be type-2er can't pick a target.

This sort of poaching probably scares away more participants because sometime legitimate participant do not update in 30 days while the exponent in being actively worked on.

So if we don't report date-updated, would-be type-2 poachers cannot determine from a single public report whether any assignment fits such a case. If we also don't report current iteration, days-to-go, or days-to-expire, would-be type-2 poachers cannot combine multiple public reports to determine whether any assignment fits such a case.

Moreover, sometimes if a Prime95 participant has some other application running at the same time as Prime95, the latter recomputes the days to finish on the basis of the amount of CPU Prime95 is getting and a very incorrect stimate of days to finish can appear on Primenet, incorrectly catching a type-2 poachers attention.

... unless we don't publicly report days-to-go or days-to-expire, that is.

3) the third and the worst method is when the poacher poaches indiscriminately without any regard to whether the exponent is about to finish, is being actively checked in or not etc.

Well, restriction of report data won't stop this type, unless we stopped reporting current assignments at all, which I don't advocate.

So what? If my suggestion stops or reduces the other types, isn't it still worth implementing?

Malfoy is the latest example in this trend though his case is particularly egregious,

I disagree. Malfoy's selections were not random or indiscriminant. He selected only exponents below M(6972593), and apparently only those in that range that seemed likely to "hold up" the milestone of DCing up through M(6972593). That's also happened before other milestones. If this behavior doesn't fit type-1 or type-2 poaching as defined, then clearly it constitutes a separate type (type-4?), but not the indiscriminant type-3. Malfoy clearly _did_ discriminate.

in the past other offenders of this type have been known to exist.

Oh?

Can anyone cite a case of poaching which was type-3, not types 1,2, or 4 (Malfoy-like) as defined above?

I'd also like to ask you - do you really think that Malfoy - when he sees three exponents blocking say M#38 - will not poach them just because there are no dates on them?? I DONT think so!

Did Malfoy poach ALL exponents below M#38, or just the ones with longest days-to-go?

Removing the information you mentioned will make all poaching type-3 poaching instead of some type1 , type2 and type3 that we currently see. And no type3 poacher will really care if we remove the info as you suggest!

So? A type-1, type-2, or Malfoy-like poacher is NOT necessarily going to become type-3 if denied target information. All the poachers who've declared themselves in past discussions here or on the mailing list had specific reasons for selecting the targets of their poaching, and all those reasons depended on having the data fields I propose eliminating from the public report.

Again, can anyone present evidence of a type-3 poacher who was definitely not type-1, type-2, or Malfoy-like as defined above?

IMHO if type-3 poachers do exist, they constitute only a small fraction of the total number of poachers. Implementing my suggestion will not increase their numbers.

[outlnder]

If I was a poacher, which I am not, I wouldn't care about days to expirey, last date updated or anything on the World Report. I would just look at what exponents needed to be done and do them.

If I'm going to steal them, why would I care about the numbers game. Put 'em in the worktodo and finish them. Done with it.

[lycorn]

Outlnder wrote:

If I was a poacher, which I am not, I wouldn't care about days to expire, last date updated or anything on the World Report. I would just look at what exponents needed to be done and do them.

That´s right, I would do the same, but... how would you know the exponents that "need to be done", without the info in the public report?
I agree with Cheesehead that that measure would help to reduce poaching. The trouble is, it´s also part of the fun to have this global picture about how the search is progressing. And there is another point: some of us (isn´t it, dswanson?) prefer to get small exponents assigned, and for that purpose it is very useful to know when small exps (LL or DC) will expire so we can, at 6:00 am UTC, ask the server for more work. Its not every day that it happens, you need to know in advance if it will be worthwhile or not.
So I would vote for leaving the reports as they are, and implementing several other anti-poaching measures, which have already been discussed in the forum.

[cheesehead]

Originally Posted by outlnder

If I was a poacher, which I am not, I wouldn't care about days to expirey, last date updated or anything on the World Report. I would just look at what exponents needed to be done and do them.

Okay.

But just how you would decide what exponents "needed to be done" if the public assignments report lacked the fields I propose omitting? Exactly what data source would you use to get the information you'd need for your decision?

If I'm going to steal them, why would I care about the numbers game.

Because you need the report data fields I've listed in order to choose which ones to steal.

Put 'em in the worktodo and finish them. Done with it.

Put which ones in the worktodo? How would you select them without knowing current iteration, days-run, days-to-go, days-to-expire, date-updated or date-assigned for any assignments other than your own legitimate ones?

[cheesehead]

Originally Posted by lycorn

I agree with Cheesehead that that measure would help to reduce poaching.

Thank you. :)

The trouble is, it´s also part of the fun to have this global picture about how the search is progressing.

So ... the administrators publish a new report that has only aggregate data for bins of assignments, but no individual assignment data.

And there is another point: some of us (isn´t it, dswanson?) prefer to get small exponents assigned, and for that purpose it is very useful to know when small exps (LL or DC) will expire so we can, at 6:00 am UTC, ask the server for more work.

But you already know the time of day, 0600 UTC, when you can ask. So just continue to ask then.

Its not every day that it happens, you need to know in advance if it will be worthwhile or not.

So ... look at the aggregate report, which should include a count of the ones available in the category you want.

So I would vote for leaving the reports as they are, and implementing several other anti-poaching measures, which have already been discussed in the forum.

But none of the other measures employs the strategy of concealing information needed for undesirable decisions from the bad guys.

[Darak]

George has spelled out a mechanism which will ELIMINATE 99% of all poaching. It’s a very well thought out plan and I see no reason any “extra” measures need to be taken once it’s updated in the new server software. As for now, there is no near term milestones that is likely to be poached now that the stragglers have all been removed from the DC’s (whether we like the manner in which they were removed or not). So waiting for the server upgrade isn’t a big issue at all from my prospective.

Jeff I’m surprised you have not suggested doing away with the status.txt file altogether. I mean by your reasoning that would certainly eliminate poaching. If nobody knew what exponents were assigned then certainly it would be hard to poach them. Granted it would drive away orders of magnitude more CPU horsepower than poaching ever did….

There are at least a dozen or so of us that have fairly elaborate status information setups and I would for one very much hate to see that done away with. I have a database which keeps track of nearly all aspects of how the project progresses over time including projected completion dates based upon past performance using long term & short term data. I noticed the day the first exponents were poached (as I’m sure a half dozen or so did as well). The first several exponents poached had a completion date based upon both historical (within the past 6 months) & recent (between the last 2 checkins) of ~7 years. Is that a reasonable completion time absolutely not. Would George’s new system prevented those exponents from stalling, yes it would have.

We are not talking about somebody who has a slow computer and wishes to contribute to the project in most of these cases (if not all of these cases). We are talking about somebody adding prime95 to Aunt Sally’s computer during a time they were interested in the project and then forgetting it was ever put on there. At first Aunt Sally’s bright new shinny P2 450 machine is plowing through the exponents since the computer is new and she is using it everyday but now a couple of years have past Aunt Sally has downloaded some really cool screen savers and have it set to 2 minutes and only boots the computer up for 30 minutes a week to check her email. While she is checking in regularly her throughput has dropped to 100’s of iterations per day. My point in all this isn’t poaching is “good” but rather our current system has flaws which some individuals feel they are patching. George’s suggestions fixes the flaws thus eliminating the “need” for the patches. Just as implementing the 60 day expiration date years ago fixed the problems people where individually fixing prior to that. Will in the future the new system have a flaw that individuals feel the need to “fix”, certainly not one that I can see at this point.

Darak

[lycorn]

Just out of curiosity, what is the projected completion date you have for the project? I mean all exponents up to 79.3M tested and doublechecked. I think it will take well over 20 years...

[cheesehead]

Originally Posted by Darak

George has spelled out a mechanism which will ELIMINATE 99% of all poaching.

It will eliminate some motivations for poaching, but will leave others, perhaps more than 1%.

It’s a very well thought out plan and I see no reason any “extra” measures need to be taken once it’s updated in the new server software.

I'm proposing a second plan which could be implemented either along with, or independently of, that other server software changeover.

As for now, there is no near term milestones that is likely to be poached now that the stragglers have all been removed from the DC’s

1) That wasn't true when I initiated my proposal.

2) If we consider only current urgency, then we don't need to consider George's plan, either ... until we near the next milestone or experience the next spate of poaching.

Why not fully discuss possible plans even when not currently urgent?

Jeff

I'm another Woods -- Richard. But you can call me "cheesehead". :)

I’m surprised you have not suggested doing away with the status.txt file altogether. I mean by your reasoning that would certainly eliminate poaching.

Exaggerating my proposal does not convince me that it's flawed.

I'm not an extremist. I've detailed precisely what to change, and what doesn't need to be changed. If anyone can demonstrate that some of the data fields I propose concealing can be left public without enabling poaching, I'll be glad to see it. I haven't proposed eliminating any report altogether, and I've suggested ways to minimize inconvenience.

If nobody knew what exponents were assigned then certainly it would be hard to poach them.

You did notice that I have not proposed eliminating that information, didn't you? If you didn't, please re-read.

Granted it would drive away orders of magnitude more CPU horsepower than poaching ever did….

Are you saying that because you think I'm Jeff? :)

There are at least a dozen or so of us that have fairly elaborate status information setups and I would for one very much hate to see that done away with.

So would I, and I have already pointed out how to avoid that in earlier posts.

I have a database which keeps track of nearly all aspects of how the project progresses over time including projected completion dates based upon past performance using long term & short term data.

... and according to my proposal (either an aggregate report, or password access to complete report), you can go right along doing that ...

We are not talking about somebody who has a slow computer and wishes to contribute to the project in most of these cases (if not all of these cases).

Maybe you aren't, but I am. Re-read my earliest posts in this thread. ALL of the multiple times I was poached _did_ involve a "slow" computer used by someone who not only wished to contribute, but was actively contributing (I'm in the early credits list) to the project.

I've noticed that respondents to my proposals each seem to have a different personal view of poaching. I guess we all do.

My point in all this isn’t poaching is “good” but rather our current system has flaws which some individuals feel they are patching.

... which they accomplish by poaching. (Hey, "patching by poaching" has a ring to it :)

You have noticed that George Woltman has _explicitly_ condemned poaching, haven't you? That he has _specifically_ asked participants to let him handle the stragglers his own way? "Patching by poaching" does not fit into that.

George’s suggestions fixes the flaws thus eliminating the “need” for the patches.

A "need" which never legitimately existed. George was quite capable of handling those flaws in his own way, but others just couldn't bear not to "patch by poaching".

Unlike other solutions, mine is aimed at minimizing a would-be poacher's ability to select a target _no matter what the motivation_. So when new motivations arise in the future, my proposal would already be in place.

Sayyy... you seem to respect George's new proposals. So what was wrong with his past proposal (No Poaching - to fix flaws or for any other reason), in your view?

Just as implementing the 60 day expiration date years ago fixed the problems people where individually fixing prior to that.

But ... but ... we've _continued_ to have poaching ... by individuals "fixing" problems they couldn't bear to let George fix in his own way.

Again, my solution is a motivation-independent answer to poaching, so would not be obsoleted by new motivations.

[cheesehead]

Originally Posted by lycorn

Just out of curiosity, what is the projected completion date you have for the project?

(Since you don't specify to whom you were addressing this question, I'll assume it's a tossup for anyone.)

Personally, I think GIMPS will not be completed until quantum computers are able to find new Mersenne primes so fast that the quest loses difficulty.

I mean all exponents up to 79.3M tested and doublechecked.

We might be beyond 79.3M before quantum computing obsoletes this quest ... but maybe not.