Quote from: satashi_nokamato on Today at 11:33:27 AM

Could you share with us whatever you have done in those 3 years? I mean this could be somewhat true that solving these puzzles could be addictive, but I'm curious to know what were you doing exactly? I just hope it wasn't sitting and watching the screen while brute force tools were running. Knowing the ways you tried will definitely help others not to try them, you can at least do that.

Oh, i feel naked in the middle of the street...

At first it was really just an observation of brute force, because i did not fully understand the strategy of “attacking” with random numbers. Then I started modifying the existing software. Finally, i came up with my own software.
I am an engineer, not a programmer or mathematician, i had to study, so most of the time i rather struggled with technologies that were new to me.
Addiction began to appear when i felt that i was influencing the process. More like an obsession.
I will have access to the code on monday. In fact, i didn’t come up with anything totally new, i just came to this conclusion:
I ran hundreds of tests and simulations and found that if a number is divided into "chunks", the probability of hitting the target increases many times. For example:

1 0000 0000 00000000

What we see: the first digit is the starting number of the hex key. If we take, for example, the 66th key, then this number can be 2 or 3. A little later i will explain what i did in this case.
The second and third groups have a range from 0000 to ffff, so, 65536 options.
I generate two random numbers, convert them to hex, concatenate them and pass them to a modified rotor-cuda so that it can iterate through the remaining 8 values. The resulting range for example:

1fb1206ac0000ffff
1fb1206acffff0000

I never iterate over the full value of 00000000-ffffffff because the likelihood of there being 4 zeros or 4 "f" at the beginning is extremely small.

If in the first chunk we generate a number within 65536**2 (1 00000000 00000000), and not two separate values 0-65535, then the simulation shows that getting into a number within 4 billion is much more difficult than hitting two numbers 0-65535 twice. Mathematics often says the opposite, but i only believe the simulation, which showed me that in this case it is much more likely.

Having a cluster of servers and an orchestrator that gave each GPU a group of new random numbers, it took me 2-4 seconds to brute force the tail of each key. Up to 40 GPUs worked simultaneously (as much as there was enough money for rent).
If the number starts with 2-3, i went through the values twice, changing the starting digit.
The second and third chunks are saved into a regular text document as one value, so the generator never hits the numbers twice and wastes no time. The maximum size of this document would be only 39 gigabytes.
I understand that going through all 4 billion options would take many lives, but my system seemed to me the only one possible in terms of probability and i still believe that it would have worked, but i no longer have the money for further experiments.

I've attached my text document with all the ~1.4 millions of chunks that i checked on the 66th key. I checked both - with 2 and 3 at the beginning. The tail, of course, was checked by brute force.
https://drive.google.com/file/d/1EeEMjnQ_6xa9S_88zPSr8OELCNkwXL3o/view?usp=sharing

Hope it helps someone.
It will be very funny if my code didn't work well. But i checked it on the founded wallets, i don't know what could have broken it.