Not really, I discarded the first number one because is a testnet, so basically I didnt screw my statistics.
Did you account for the implicit "1"s I mentioned about?
E.g. in decimal if I give you the number "42" but you also know it's a 64-bit value, there are implicit "0"s in front of 42, if your goal is to make some stats on base10 digits of 64-bit values. Because it would not be fair to only count 0s in numbers such as "402", "420", "81505" and so on.
As I said,I didn't have time to take a look in running in decimals yet. It's in my to-do list, and I'm surely will take a look to see if any patterns emerged
Same principle for a BTC address. For base58 the implicit symbol is "1" (the first symbol of base58).
This has nothing to do with the "1" which you actually see at the start of an address. And even more, if you have multiple "1"s at the start, all of them are just a convention that says "so many bytes at the start are 0x00", NOT "this so many digits at the front of the base58 representation are 1". So some work is involved here if you truly want to make a histogram on base58 usage (which I don't really understand why you would, it's much more direct and error-free if you just use the binary representation).
I believe you didnt get what I was pointing out:
Cryptography, as any most mathematical techniques, consist in change a one space to another space... we do this all the time, transform x,y,z in polar coordinates, exp and so on...
What I may didn't said is:
Any exchange of spaces has strength and drawbacks, they are the sides of the same coin.
Some pattern can and will emerge when you change spaces.
Initially, i imagined change for an log space, but now I see can have other functions fitting better with what I'm seeing.
But something similar happened when I worked as statistician in developing games for casinos:
We need to work hard to looks "most random as possible". It's way more complicated than you think.
The greatest problem is human perception of randomness is not the same as computer randomness, that's why most lottery game are made by functions like that and I proved decade ago this
(I was just a broke uni student, and I didn't had credit to put money where my mouth it is, unfortunately 
)That's why this puzzle really tickles me: I know I can do it, time and money is all I need tho
Stop looking for logic, all the addresses of the puzzle are random.
And using python is 100% a waste of energy.
Don't dream idly.
Search in a small space (for 66 or 130) and hope for luck.
99.99999999999999999% JUST FOR FUN
Of course, money is a great incentive (i never needed so much in my life like now) but is a great way to take the rust of my mathematical skills.
If you think is a waste of time, is your opinion and good luck for you.... is just not mine
Furthermore, I didn't found any explanation why has this preferential for some letter if is a "random math base equation" even if you use other hexadecimals. Is this not defeat the entire propose of been random?
Modulus bias. It is not about the random function, it's about the domain size vs. the modulus (base in this case) which is used. base58 is just done like in any other case: divide a big integer,
use remainder, repeat with quotient.
That's a high possibility, but again, when pattern emerges, even if is not a bijective function per say, the areas of search reduce considerabily
Maybe run the stats on the base2 160 bits instead?
That's a possibility, but when you have a bias, you have a weakness
The only bias here is about the bias of base58 representation, not on RIPEMD.
We need to develop a multi-threaded algorithm with the following structure:
Thread 1: This thread generates starting keys and stores them in a global array.
Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array.
Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array.
Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately.
Maybe it will be faster this way? I don't know.
But i believe an better strategy:
3 threads - one produce addresses, the other just check the first 4 digits, and other comparing the pool generated by the second one.
Why? Because you save time by just run the first 4 letters.
I was watching a yt about a billion data points challenge and they run the analyzes in less than 3 sec with java!
If someone can do this in rust/c/java, I will give a hug, please, i need it!
Because python....no,no,no... unless you want you house burn down
I did it in C. PrivKey (sequential) to PubKey to RIPEMD and then memcmp with the static constant target RIPEMD (which ofcourse returns false as soon as the first byte is different, come on...). You CAN't do it faster than this, and it can only scale linearly with thread count. But it's quickly obvious that it's unfeasible, I mean it's the only real way to do it without knowing the public key, but it's both a O(n) complexity AND it involves SHA256 + RIPEMD at every step.
I was searching yesterday about Bend and the Multi parallel processing for python, together with some other ideas:
- Instead to search for letters use the decimal code cuz been an integer is faster than base 58, around 30% of the speed
- KAN machine learning (maybe
) still very new so IDK tbh, but is a possibility nevertheless.
- dedicated 2 mini pcs and only the list been for another computer
(mine is worse than a potato)
- use old phones to do some part of the search.... is not fast but is something
That's why I strongly believe #130 will be found next, not #66. Much more room for breakthroughs and exploration there, and while the complexity seems similar it runs WAY, way faster (no hashing nonsense).
btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.
can you explain more about? I didn't get it, sorry
Now I need go back to work... see you later
odd to say at least