The sum of all probabilities is always the same, no matter how you “divide” the possibilities.
I thought so too until i started running simulations. I'll explain later.
This is a very complex way to lose performance instead of simply generating a single random number.
Exactly the same waste of computing power, i don't understand how you came to that conclusion.
Numbers are not "converted to hexadecimal", they are numbers. Views are converted.
I know. The way we see it, numbers look visually simpler than hexadecimal. I didn't say that the results are different.
I don't need to prove to anyone what i see, but if it helps someone, the logic is simple:
Imagine a slot machine. It has 1 slot with 65536**2 options. One generation = one rotation.
The pseudocode is simple:
long a = rand(1, 65536**2);
int count = 0;
while (True) {
count++;
if (rand(1, 65536**2) == a) {
a = rand(1, 65536**2);
count = 0;
print(count);
}
}
Now try the same thing, but with two slots of 65536. I already said earlier that, despite the identical number of options, paradoxically, the frequency of two numbers appearing in a row of short numbers is in most cases much higher than only one, but long number.
This works up to the third or fourth "slot". The more there are, the less chance there is. Thus, generating all 8 characters results in almost zero chance of "catching" the desired value if you not exclude a second hit.
There is no need to guess one value out of extra large. You can significantly narrow the search if you combine ranges and brute force. That's all what i'm talking about.
In the case of the 66th key, the range is reduced from 2*4294967296*4294967296 to 4294967296.
The ranges that are in the text document above cost me over $60k. If someone tells me that this helped him narrow down his search and he found the key, of course i won't be happy for him, but maybe it's comforting to know that i screwed up so that someone else wouldn't (no).
There is nothing more to talk here, it's over. Just take my ranges.