Quote from: kTimesG on Today at 02:55:48 PM

...
Aham. Is that the speed of actually computing and hashing a key, or it's the speed of "hey, let's skip some keys because I think they look unlikely" or "hey, let's use endomorphism even though it's useless for searching a range"?
...

No, the speed per Nvidia GPU is real, as I wrote, this speed-up it is not "skip-hash". The speed GPUs run at, such as 6800 Mkey/s per RTX 4090 at full 100% power limit, is not achieved by skipping anything. It is a real hash reached by heavy CUDA optimizations I did. Full keys are being checked at this speed. My version can go even normal one-by-one scanhash with 1 stride at this speed just as original Bitcrack did without skipping anything.

I heavily modified Bitcrack, did a lot of work, in a way that it is only loosely based on it now. What my experimental version does is, when running in "skipping approach" and "forced pattern(s)" mode, it first selects hex private key candidates based on criteria being set prior to start, and then it fully hashes only those at full speed on respective GPUs in the given range, just as if it was a normal scanhash, but being done on selected keys only, instead of stride by 1 mode. Everything is done in real-time on GPUs, the time consumption of ruling out and selecting private keys in pre-selection CUDA kernels based on criteria is negligible, usually less than around 1% of the speed of each scanhash cycle. When candidates are selected, they are fully hashed and checked at real hash GPU speed, as was said.

Anyway, about this approach, simply my idea behind this experimental puzzle private key finder is that I am not looking at a given private key range as a hexadecimal representation of a number, and instead it is seen as a set of '0..9' and 'a..f' characters, numbers, and letters - a string - more appealing and nicer to the human brain. Cheesy

Yeah, I realize it may seem pretty ridiculous at first glance, to work with it like this, but well, I like things like that.
I call it cherry-picking from a cake approach.

It is much more fun, but what is more important is that it also adds real effectiveness to search of lower bit BTC puzzle keys.
I mean, there is no reason to compute something and waste computing resources on something that will never lead to a desired solution.
Right? Or is it?!? No, it is not.

Let's think, will the private key (the ending part) of #67 contain only numbers "0x41285418271284394" or only letters "0xFCAFECDBCAFEFCABD" when looking at it as a string of characters?
Will it? A randomly generated private key from BTC puzzle will be like that? No!
It is so unlikely that I would even dare to bet my own life on it that no. No way!

So, does it make sense to compute priavte keys that are like this in one-by-one scanhash with 1 stride? No, it is a waste of GPU computation resources.

When searching for #67, any private keys of this sort can be completely ruled out and not computed at all.
As there is no reason to fully compute and check them, they will never ever lead to the right solution, never will they lead to the private key for BTC puzzle #67.

And this is what this approach is about. Just fine-tuned by far more parameters than in this simple example. My reason for this approach is to reasonably rule out as much as possible improbable private key candidates, to balance out the very low count of GPUs I own, to save on every possible hash, and to save on every possible computation that will lead nowhere, to save where I can, in hope of cutting computation times, such as in the case of #67, from hundreds of years when what it would be if it was done in a regular 1-stride scanhash to something reachable in my lifetime, ideally in years, maybe months, with some luck when doing this "skipping approach" and "forced pattern(s)" mode in my experimental solver.

My approach is just like that, I just try to do it in more sophisticated way. Such as, in the case of #67, my experimental version of Bitcrack can be ordered, based on parameters prior to start, to do all private keys from a given range, but forced to contain, looking at the private key as if it were a string of characters, for example this:
---
At least one "letter-letter" next to each other anywhere in the string, at least one number "5" anywhere, but not more than 3 occurrences of number "5" anywhere, at least 3 times "any-number" anywhere but lower than <8, at least one occurrence of "D" anywhere, and must not contain any occurrence of "letter-letter-letter" or more occurrences, no number "7" anywhere in the string, etc., etc.
---
My Nvidia GPU solver does things like that, as was set selects candidates in the given range, real-time. And then it goes, full scan-hash cycles, at full GPU speed, but only on private keys that meet given criteria untill end of given range is reached.

Yeah, this cherry-picking from a cake approach is still based on luck, but I try to fine-tune it by far more parameters and far more probability approaches I am experimenting with all the time, with ways that appeal to me as likely, as the ones that could lead to private key of low bit BTC puzzle wallet address.

As I already said, ruling out key candidates like that, depending on how many elimination parameters and patterns are being set, results in huge speed-ups. These are those "skip-hash" speed-ups; these can be in tens, hundreds, or even thousands of multiples of the original speed of the device, but naturally, depending on parameters greatly increase the risk of skipping the right solution.

Unfortunately, there is no other choice to me than to risk it with fine-tuned "skip-hash", as I don’t have thousands of GPUs in a hall big as a football stadium to solve it in some reasonable time using one-by-one scanhash with stride 1, I have only a few Nvidia cards, so I must somehow, in a reasonable way, in a reasonable balance between risk, probability, cut solving times from hundreds of years to perhaps months, weeks, or maybe even days with some luck, using various parameters to select private key candidates in my experimental solver in effort to pick cherries from a cake.

That is all there is to it. No mystery. Grin