On the other hand, the proportion of such "beautiful numbers" in the search ranges is probably no more than ~ 20%, that is, not very much. But maybe I'm wrong, and you're excluding certain numbers for some other reason.
I'd say the proportion of "unlikely patterns" in a private key of size
n is more like very close to 0.00% (zero percent) the higher
n gets. And it goes towards 0 really fast as
n grows exponentially.
The amount of the sum of valid distinct combinations when selecting k elements, from a set of n, is massively larger towards the middle (n/2) and the close ranges around the middle, compared to the edges.
And this gap gets tighter and tighter as n increases, resembling a straight up point in the middle, which contains when looking at it with a "microscope" 99.9999% of all the possibilities. Everything else (the 0.00001%) is in the ranges before and after the central point.
This is called the central limit theorem (long-term, all results will be around the average). If this law would be invalid in observation, then it would mean randomness is not part of the structure of the game, and bias of the phenomenon (a fake coin, a compromised dice, non-random generated bits) can be proven with 99.99% certainty, But guess what, we have solutions already found with sequences of eleven consecutive
1 bits, and all the other sorts of sequences of 1 and 0 as well, which if you compute probabilistically, are not at all far away from the statistical model of a randomly generated phenomenon, so...? Excluding patterns just complicates the efficiency of the search, not sure I would play such a gamble (higher bid, lower reward).
Really depends
In the grim reality, the problem is most of randomization in computer level are not real random.
We suffer this problem a lot in my area where what should be random always have a bias or a preference.
Now coupling that with a codes with more than 10 years old code who may has more rudimentary random generations comparing with modern scripts....
I worked 15 years ago with similar code generators.... and yet, we saw prevalence in some number generation, clusters and sequences, even if you use different seeds, some numbers where significant more prevalent than others.
That's why I'm doing the calculation by hand, I can see more clear patterns arising and reducing the range.
It will take a while, maybe, idk sincerely, but I want to try another route bc I don't have a GPU
Another point is not having a pool of checked addresses.
So, is we think code like bitcrack or keyhunt have also "random", chances are, in a long run with enough computers, we are double-checking some addresses, losing time and computer power in the process.
Can be small headache, but as an example of that: on
https://privatekeys.pw/scanner you can see have several people with more than a trillion addresses checked.
The caveat is many times will be in sequential mode for puzzle 66;aka recheck the same first addresses over and over.
My perspective of this challenge is to prove with the extended public key + child private key you can discover all keys.
However we are going by brutal force, and as a mathematician, i prefer to be more in a elegant way even if takes more time... and that's why i'm trying to resolve this puzzle
C is of course more performant and much more efficient in these computing areas. Python can hardly keep up.
