Bogus ECM results (?)

[lycorn]

A user identified as "Maciej Kmieciak" has jumped to first place in the Top ECM Producers page. It happened early this morning (UTC time) as far as I could tell.

Now the thing is the credit was earned by sibmitting hundreds (or thousands, I am not sure as I didn´t have the time to properly check the page and now it has scrolled down) of results for the very same exponent, at exactly the same time.

Given the absurd amount of credit I honestly don´t trust those results.

Any chance of a moderator/Primenet administrator having a look at it?

I just verified the exponent is19693327 and the number of curves recorded is so large that it appears as checked until well in to B1=44000000 (8695 curves!)

[Uncwilly]

I pm'ed Aaron about this.

[lycorn]

[Madpoo]

Originally Posted by lycorn

A user identified as "Maciej Kmieciak" has jumped to first place in the Top ECM Producers page. It happened early this morning (UTC time) as far as I could tell.

Now the thing is the credit was earned by sibmitting hundreds (or thousands, I am not sure as I didn´t have the time to properly check the page and now it has scrolled down) of results for the very same exponent, at exactly the same time.

Given the absurd amount of credit I honestly don´t trust those results.

Any chance of a moderator/Primenet administrator having a look at it?

I just verified the exponent is19693327 and the number of curves recorded is so large that it appears as checked until well in to B1=44000000 (8695 curves!)

It's M17693327 (guessing the "9" was a typo).

Besides a CRAZY amount of ECM results for that exponent (157,785 of them), he's also turned in a lot of TF work in the 192M range from 2^70 to 2^71 but those are probably fine... there are factors being found in there (25 factors and 1755 no factors since Jan 1st, or roughly 1.4%).

My guess is the massive ECM dump is a bug because it's submitting the same result over and over. The results started at 2019-02-11 22:53:27.500 UTC which cleared the ECM assignment on it, and it then proceeded to keep turning in the result until 2019-02-12 06:08:59.030 UTC (nearly 8 hours ago).

They all have the same text in the message (same assignment ID, curves, bounds).

What I'll do, since it's a VERY safe assumption this is a client communication issue, is remove all but that first one.

In the meantime I'll have to check with George and see if there's anything we can think of to explain how this happened. A client sending the same result over and over isn't unheard of... usually it means it sends the result and gets checked in, but there's some network or other issue that prevents the client from getting the thumbs-up so it knows it was sent.

I'm probably terribly wrong about this, but I also remember some kind of issue with a client where it didn't have permissions to clear the prime.spl file (or whatever it is these days) even though it was able to write to it at some point. So it clears but then the client sees the file is still there and sends again. Could be totally unrelated or off base on that but that's my recollection of something that happened before.

[Maciej Kmieciak]

Hi!

It's me. I did this and I can tell you how it happend. (Sorry for my English, I'm from Poland, I'm 15 and I'm learning.)

I've been using this program for about a year. As anonymous first, later with an account. I have used manual communication in recent months to have more options with assignments. And yesterday, when I was sending the ECM result, I discovered then I can paste this result as many times as I want. Nothing will stop server from giving me millions of GHz-days for tens of thousands of copies of the same result.

Sorry for trouble and the mess I've made. Maybe it will help improve security. I think there should be some kind of verification in case of such action which would block the results.

[westicles]

Originally Posted by Maciej Kmieciak

And yesterday, when I was sending the ECM result, I discovered then I can paste this result as many times as I want. Nothing will stop server from giving me millions of GHz-days for tens of thousands of copies of the same result.

Wow. You know, I think you could have just multiplied the number of curves by 150k and submitted once, it would have saved you all the time and trouble.

[Uncwilly]

Originally Posted by Maciej Kmieciak

Sorry for trouble and the mess I've made. Maybe it will help improve security. I think there should be some kind of verification in case of such action which would block the results.

With ECM, TF, and P-1, there is no way for the program (as it is currently built) to prove it did the work. With LL testing there is the residue that can be used to prove the result. There has been talk over time about doing something (adding a little bit of code) that will show that the calculation did get done. It will slow things down a little. The trade-off of losing time vs. preventing fraud has been assessed and the choice is to keep the current system.

I have some ideas for what can been done to show that the work has been done. (Ways to document the right work and amount has been done.)

[lycorn]

Originally Posted by Maciej Kmieciak

And yesterday, when I was sending the ECM result, I discovered then I can paste this result as many times as I want. Nothing will stop server from giving me millions of GHz-days for tens of thousands of copies of the same result.

Wait... are you saying you did actually paste the result over 150k times?
The results were received over a period of ~7h15m, or 26k seconds, so they were recorded at a rate of 6 per second. How on earth have you done that manually?

[Madpoo]

Originally Posted by lycorn

Wait... are you saying you did actually paste the result over 150k times?
The results were received over a period of ~7h15m, or 26k seconds, so they were recorded at a rate of 6 per second. How on earth have you done that manually?

Well, looking at the logs, it wasn't a single post to the manual_result page, it was more like 78 calls total. The size of each of those batches varied so I couldn't say what the average # of lines per POST was.

Depending on the size, each call took over 40 seconds each for the largest ones, or maybe only a couple seconds for smaller amounts.

Whether he submitted each of those manually over the course of 1.5 hours, I don't know, but that's kind of weird to imagine someone just sitting there doing that for 90+ minutes. Might have just done the POST using a program/curl.

As to why the server showed those times over a much longer period, probably because the server had them queued up and since it checks them in sequentially, it took time.

All in all, it wasn't a nice thing to do (we do need to rely on the honor system to an extent), but this does show that stuff like this gets noticed. And when it does, we'll strip out the bogus bits.

There's really nothing to gain by doing things like this... you only end up getting named and shamed, so let's learn from this and don't do it again. I did dumb things when I was younger too.

[De Wandelaar]

Hi,

Another case could be examined : user Samatha sent from 6.21 till 6.23 a bunch of TF results (2^1 --> 2^80 or 2^82), mainly in the range of the 900 Mio with always NF as outcome.


Total Ghz/day : 3399202.193 !

Yves

[petrw1]

Originally Posted by De Wandelaar

Hi,

Another case could be examined : user Samatha sent from 6.21 till 6.23 a bunch of TF results (2^1 --> 2^80 or 2^82), mainly in the range of the 900 Mio with always NF as outcome.


Total Ghz/day : 3399202.193 !

Yves

Are there gaps in her range. I've seen cases of users sending in thousands of NF in a batch then all the corresponding F a few hours later.