I'm a Newbie

[davieddy]

I have been assigned a LL 47M+ test, described by a ~32 digit hexadecimal number.

WTF does said number mean?

David

[TimSorbet]

The number you're referring to is the Assignment ID. It's a randomly-chosen number to let PrimeNet know you're the proper owner of that assignment. It has nothing to do with describing which number you're testing: that's described fully by the 47M number. (the number you're testing is 2^47xxxxxx-1)
In case you're wondering, the other numbers in your assignment line are the TF bit depth complete, and a 0 or 1 indicating whether P-1 has been done.

[davieddy]

Originally Posted by Mini-Geek

The number you're referring to is the Assignment ID. It's a randomly-chosen number to let PrimeNet know you're the proper owner of that assignment. It has nothing to do with describing which number you're testing: that's described fully by the 47M number. (the number you're testing is 2^47xxxxxx-1)
In case you're wondering, the other numbers in your assignment line are the TF bit depth complete, and a 0 or 1 indicating whether P-1 has been done.

THX Mini-Geek.
Nice to hear from a fellow Newbie.

David

PS are you sure a random integer between 0 and 16^32 is
sufficient to guarantee distinctness among the considerable
number of GIMPS participants?

[CRGreathouse]

Originally Posted by davieddy

PS are you sure a random integer between 0 and 16^32 is
sufficient to guarantee distinctness among the considerable
number of GIMPS participants?

Lots of collisions amongst the numbers would happen around sqrt(16^32) = 2^64. Probability of a collision with 100 million participants: < 0.0000000000000000000015%. Probability of a collision with 1 trillion participants: < 0.00000000000015%.

So no real chance of collisions, unless there's bias in choosing the numbers.

[cheesehead]

Originally Posted by davieddy

PS are you sure a random integer between 0 and 16^32 is
sufficient to guarantee distinctness among the considerable
number of GIMPS participants?

I doubt it's actually random or even pseudorandom. My guess is that it's merely a disguised combination of exponent, user ID index, timestamp at assignment creation, and maybe something else.

[sdbardwick]

I assumed that it was just a T-SQL uniqueidentifier.

[TimSorbet]

Originally Posted by cheesehead

I doubt it's actually random or even pseudorandom. My guess is that it's merely a disguised combination of exponent, user ID index, timestamp at assignment creation, and maybe something else.

If it's not (pseudo)random, it certainly doesn't follow a clearly-visible pattern. In two separate assignments of M60120113, (with the same exponent, reserved by the same user, at times only a couple minutes apart, by your theory they should be nearly identical) I got the keys:

4474A6D9EBB0EEBEC1AE1B96C074AA95
DFDF24E002E2E4FAC4B4EB9E026640CE

(if even only the exponent was in there, I'd expect to see 3955C31 or 60120113 somewhere in both, or at least C31 or 113; but there is no obvious matchup)
As you can see, they bear no obvious resemblance to one another. If it was a disguised combination of information, it must have been passed through some sort of hash. Coincidentally or not, it is the same length as an MD5 hash (32 hexdigits). But then it's also the same length as MS's GUIDs, such as T-SQL uniqueidentifier as sdbardwick suggested.
I think it's most likely random, considering all I know. (e.g. there doesn't seem to be any benefit to encoding all that sort of data in there, PrimeNet could just link the unique key to all of the information)

(note for all newbies and others: generally you shouldn't post your assignment keys publicly, but in this case I unreserved the number before posting it, so PrimeNet knows those keys are now for canceled, and so invalid, reservations)

[Uncwilly]

Originally Posted by Mini-Geek

If it's not (pseudo)random, it certainly doesn't follow a clearly-visible pattern. In two separate assignments of M60120113, (with the same exponent, reserved by the same user, at times only a couple minutes apart, by your theory they should be nearly identical) I got the keys:

Isn't that the hallmark of a good encryption code? It should seem chaotic.

[chalsall]

Originally Posted by Uncwilly

Isn't that the hallmark of a good encryption code? It should seem chaotic.

Indeed...

mysql> select MD5(1),MD5(2),MD5(3);
+----------------------------------+----------------------------------+----------------------------------+
| MD5(1)                           | MD5(2)                           | MD5(3)                           |
+----------------------------------+----------------------------------+----------------------------------+
| c4ca4238a0b923820dcc509a6f75849b | c81e728d9d4c2f636f067f89cc14862c | eccbc87e4b5ce2fe28308fd9f2a7baf3 | 
+----------------------------------+----------------------------------+----------------------------------+

[davieddy]

Originally Posted by CRGreathouse

Lots of collisions amongst the numbers would happen around sqrt(16^32) = 2^64. Probability of a collision with 100 million participants: < 0.0000000000000000000015%. Probability of a collision with 1 trillion participants: < 0.00000000000015%.

So no real chance of collisions, unless there's bias in choosing the numbers.

The Birthday problem.

If I was thinking of anything constructive when
I started this thread, it was along the lines of
"How not to deter non-math newbies from joining GIMPS"

David

[CRGreathouse]

Originally Posted by Uncwilly

Isn't that the hallmark of a good encryption code? It should seem chaotic.

Avalanche effect?