Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
However too (lol), in doing this and that and testing this and that, I feel like I have a better method for identifying "more than likely" ranges and the whole work distribution, than I had in the past.
P.S. If my bot says I found the key, reach out to me...LOL
P.S.S Still a lot of openings in the Beat Bram donations/crowdsourcing
Oh, man. I really hope you're not influenced by getting a few unlikely strikes sooner than expected, like your 58-bit hit last night.
Hitting the end-tail of the distribution does not mean it stays there long-term. By long-term, I don't mean scanning another 0.01%, but rather maybe long-term to the point of having chances to hit something like a 67-bit prefix.
I already gave a counter-example: I applied the prefix theory / gaps / however you want to name it over 9000 trillion keys, and the results were worse then by simply scanning sequential.
In other words: I never stumbled on a 53-bit key. More smaller-prefix lengths? Yes, indeed. But how in the world would that ever be useful for anything, except as a base for "please scan more"? Where was the "we can avoid scanning a vast amount of the search space" in my experiment? Well, probably in the skipped regions, but going over those as a backup simply means I was better off scanning in sequence, or am I missing some wisdom?
I don't waste anytime/hashes nor skip to the "next" range and sit there until I find another one lol. The partial matches you have seen coming in...I do nothing with them. Just collect them. I've already entered all the ones I will enter for 69. We over here gap filling now lol.
To keep it simple, for now. I only collect x amount of partial h160 matches. Then I create my db and start filling in the gaps. The number is still fluid as I am trying to tweak it based on available resources (CPUs/GPUs). But for 68, I did not have the actual key buried and was right at 2^32 keys away from solving. It all comes down to firepower. If I would have had about 1,000 CPU cores and 15-20 more GPUs running for 68, I may have found it before Bram. I was walking that range in. Obviously, more fire power, the quicker it would have been.
Did you just replace range skip by range selection ?
At some point you have to start filling in the gaps, running sequential ranges. I said this when yapping back and forth with McD.
Think about it, if you just kept randomly searching for partial matches, and the actual key was buried inside a padded range, you would never find the key. Mine is different from Bibli and McD's original plan. I've said all along, you have to track what you have searched or you could go into an infinite loop. I have about 4 different "methods" entangled in my method.
I haven't looked at the testing code yet, but it probably isn't 100% to what I am doing...but I said posts back that I believe both ways are a wash, and both would average out to 50%. However, another test would be to test Bibli's method, where it is find a match, skip keys, find another match, etc. It may not be as basic as that, only he can answer.