Obvious, it is because the things their computing capabilities are being utilized with are ultimately more lucrative in the end of the day than solving BTC puzzles.

Rules of omitting or requiring certain "letters" and "numbers" from the hexadecimal key "string" I mentioned were examples to demonstrate what my experiential finder is capable of. I use various and different patterns and methods of this sort. I change them often, experimenting. That is the reason why I created my version this way, so private key selection can be manipulated based on given "string" criteria.

I needed to choose some criteria by which to manipulate odds and cut down BTC puzzle scanhash times from hundreds of years to something lower, something that can be done in months, weeks, or days, based on given rules, "skip-hash".

Is it rational from a mathematical point of view when speaking about any generic BTC keys?
No, not really at all. Is it ridiculous? Yeah, kind of to some extent, surely. And what?

I really understand everything you mentioned, I get everything. I knew it even before.
I have been programming since the 80s, I have (surprisingly) degrees in mathematics and computer science, and (this is very scary, LOL...) I have been lecturing those for quite some time in the past.
In the late 90s and early 00s, amongst other things, I worked on AAA game titles, programming 3D engines, game physics, logic, and visual renderings in times when it was pretty hardcore and a lot of things needed to be figured out and done "on the knee", not as easy as these days. And many other things related to the field up to this time.

I realize heavy storm clouds can sometimes resemble dragons, or sheep, or something creepy, depending on mood, as it is the way the human brain likes to make associations and tries to find patterns and see things where they are not really. Yes, of course.

Is my experimental Bitcrack version a scientific tool? No, no way. It never was. That was never the intention.

Is it a kind of tool where I can predict, bet, and try searching for private keys, looking at them as "strings" consisting of "numbers" and "letters" and based on given criteria, restrictions, and patterns, where I can experiment with various prediction and probability systems in it? Yes, this is kind of what it is.

Searching for a private key with it is based on luck, as was already told, it can be said "skip-hashing" depending on parameters, my way of picking cherries from a cake approach.

Is it rational? Well, it is my approach, be it rational or not, I still stand by my opinion that it adds effectiveness when searching for BTC puzzle keys. I repeat again - puzzle keys.
As this is what it is about, I do not care about common BTC private keys, generic BTC private keys. I care only about the low-bit BTC puzzle keys.
Yeah, I know they are random too, yes, yes, ... yes, I know that if they were in a different format it would be different.

I had to approach it somehow, so I chose to look at keys as hexadecimal "strings", simply like that, it is nice and appealing to see them as single characters, "numbers" and "letters".

As I already told, I don’t know exactly what BTC puzzle key #67 (the ending part) looks like, but I am pretty sure it doesn’t look like this, for example:
All characters of #67 are "letters"? No. All characters are "numbers"? No.
The first part of the key is only "letters" and the other part is only "numbers"? Or vice versa. No.
It is like exactly "letter-number-letter-number-letter-number..." till the end? No. No way, I would even put my hand in the fire that no. Yes, this approach is about betting on something and holding to it.
Etc.

I made my experimental finder this way basically because already solved puzzle keys are usually published in hexadecimal "string" format, and when I always looked at some already solved BTC puzzle keys, I told myself something like, ahhhhh... I knew that "EE" would be in it, or I thought there would be zero occurrences of "4" anywhere in this one, things like that.

Thus, I made myself a GPU tool exactly for that, so when I want, I can scan a given range fast on my few Nvidia cards using any sort of "string," "letter(s)," or "number(s)" criteria. Such as, I want to scan the given range but omit number "4" anywhere in the "string" I can, I want exactly 2 letters "EE" to be anywhere in it next to each other, I can, I want to have any unknown "letter-letter" anywhere in it, of course, I want to have an occurrence of exactly 5 unknown "letter" in it anywhere, no problem. I want it to skip all private keys containing more than the count 9 of any "letter" anywhere in the string, yes, or at least the count of 3 "number" that has to be lower than <8, sure, things like that, etc.
Any pattern, any sort, operators, conditions, any offset, anywhere, any count.

With this, I test my chances in ways I needed and I test various probability systems and approaches I like, new perspectives I try to figure out, I experiment - it is fun, and I hope for luck.

Anyway, what I wanted to say about it, I already said, speaking about it more again and again now would be going in the cycles round and round.
As I already told you, if I ever solve the low-bit BTC puzzle with it and finally the price will arrive at my BTC wallet without being robbed during cashing out by a bot run by a thief, I will publish it, including the source code.

Till then I will be trying my luck with it.
I am pretty stubborn when I bite into something, be it rational or not, I don't care.

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.

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.

For low-bit BTC puzzles, I use my own experimental, slower version that I wrote in C++ loosely based on Bitcrack, but with heavily optimized CUDA kernels where its sequential scanhashing is from 80% up to 120% faster, depending on the Nvidia GPU model and architecture, than the original Bitcrack.

My Nvidia GPUs go like this with it, depending on card OC, at 100% power limit up to:
GTX 1080 Ti, 950 Mkey/s
RTX 2080 Ti, 1800 Mkey/s
RTX 3090, 3700 Mkey/s
RTX 4090, 6800 Mkey/s

In addition to significant optimization speed-up per GPU, my version has also modified scanhash search logic to be able to run in "skipping approach" and "forced pattern(s)" mode, where the search is sequential but only on given data candidates. In this mode it doesn’t go one-by-one, one key after another with 1 stride, but instead keys are preselected in real-time over and over again on the fly during running, eliminating certain patterns from hexadecimal "strings" being based on tune-able parameters.

I realize the fact that BTC puzzle keys were generated using a Deterministic wallet randomly, meaning there is no real pattern behind them to search for; however, the purpose of my version of Bitcrack is something else. It is to eliminate very unlike private keys, not compute something that is very unlike. Such as in a 17-character hexadecimal long key range, the ending of the BTC puzzle key #67, which is randomly generated, it is so unlikely that it will contain only "letters" (0x6AFDCBEDCABEFDA) or only "numbers" (0x40124579147074121) that you can put your hand in the fire for the fact.

This is what my own version of Bitcrack can do on my GPUs. It can be ordered by various parameters prior start to skip, or oppose forcibly require, or both at once unlimited times by parameters, puzzle keys that meet fine-tunable criteria, for example to skip numbers only ('0..9') or letters only ('a..f'), skip hexadecimal "string" candidates that go one after another, exact "strings" 0xFF, 0xAAA, 0xCCCC, or exactly unknown "strings" letter-number-letter, or letter-letter-number-number, whatever of this letter-number sort, anywhere in hexadecimal representation of key at any position and any offset, even on multiple locations or unknown locations and offsets, or reverse it can be ordered and forced to do only wanted "strings", various thresholds, equal, less, higher, non-equal to whatever parameter set and much more.

I already described it in my previous post some time ago:
https://bitcointalk.org/index.php?topic=1306983.msg62088633#msg62088633

As I said, I fully realize puzzle keys are in fact random, but to do it this way is still much more fun than by simple one-by-one, 1 stride scanhashing.

I use even more approaches than these, in my experimental solver I simply try algorithmically manipulate chances, moving chances of finding a solution to my side, and skipping non-interesting candidates that are very unlikely without any hashing to balance the risk of skipping the right solution and to balance out this way a low count of GPUs I have. As ruling out key candidates like this results in hardware computational speed-ups that are tens, hundreds, or even thousands multiples of the original speed of the device when searching whole/given range, but naturally depending on parameters greatly increase the risk of skipping the right solution.

Anyway, if I solve some low-bit BTC puzzle with my version and finally the price will arrive to my BTC wallet without being robbed during cashing-out by a bot run by a thief, I will publish my version of Bitcrack, including source code, so anyone can have fun with it then.

Of course, all developers and contributors who, in a positive way, added to BTC puzzle-solving approaches deserve donations. That is without any doubt and out of the question. I actually would consider it something obvious and completely normal that the one who solves the puzzle would donate some BTC also to other people, but I understand people are of various natures and kinds.

Anyway, if this is mainly about BTC puzzle solving, one would expect that the best candidate who would actually deserve a donation from the puzzle creator is the person who initially solved #66, as he was able to fulfill the original purpose for which the BTC puzzle was created in the first place but was robbed through RBF during price cash-out by a bot run by a thief, who, instead of being at least silent, keeping his mouth shut, and giving minimum half BTC back to the original #66 solver, was so insolent that he even dared to mock this person with some, only according to his head, kind of wannabe-wise messages left in BTC addresses. Primitive psychopath.

Yes, that RBF act was theft. There is no doubt, morally as well as legally.

Taking price from BTC puzzle upon finding the right solution based on skills and effort is completely legal, as that is what the puzzle was created for, and it is done with the well-informed consent of the puzzle creator, owner of BTC stored in puzzle addresses, but using RBF to replace outgoing mempool transaction during the cashing-out of BTC puzzle price is robbery. You can try to justify it and paint it as pink in whatever ways you want. It is a criminal act, nothing else.

The fact that the original #66 solver made the mistake of going through the public mempool doesn’t change a thing about it.

Why fishy? It makes perfect sense. By solving #120 and especially #125, he had enough BTC, so there was no need to bother further with solving #130 immediately, thus leaving #130 for other people to showcase their skills, but as no one managed to take the opportunity, he came back and solved #130 by himself, not for crypto, but for prestige, and prestige will be even higher once when he solves #135.

Solvers of BTC puzzle #125 and #130 are one and the same person.

Yes, but when such a bot is set on a computer that is always online 24/7, for years, such as on a mining rig, even dozens of such bots can be running on said machine, checking transactions in the mempool every second for interesting puzzle addresses, being prepared for RBF, and it will have a close to nil impact on the overall function of such build. So it is no big deal for said bot even if it runs and waits for long years, the potential profit is tempting, and the cost of running it is absolutely negligible, as such a mining rig would be online 24/7 anyway, computing other things, while the bot is lurking for prey.

I am using this solution candidate skipping approach in my custom solvers for long years.
The idea is that it should not be looked at given key range as hexadecimal representation of number and instead it should be seen as set of '0..9' and 'a..f' characters, numbers and letters, a 'string'.

Considering the fact that BTC puzzle keys were generated using Deterministic wallet and not by human mind, not intentionally formed, it is very unlikely that private keys, hexadecimal strings of longer range puzzle keys will be numbers only ('0..9') or letters only ('a..f').
Such as 0x20124579147074121, or 0x3FCAFDCBEDCABEFDA in case of puzzle #66, no way.

In 17 characters long key range, that is randomly generated, it is so unlikely that you can put your hand in the fire for the fact that there are numbers as well as letters in range string of correct solution leading to private key of puzzle #66 BTC address.

So why to waste hardware device resources to compute something that will never lead to desired solution? There is no point for that at all.
Those private key candidates can be effectively skipped without any hashing computation, thus resulting in solution finding speed-up.

How much speed-up depends on amount of ruled out potential key candidates that will very likely never lead to desired solution and doing it by far more parameters than just simple numbers only ('0..9') or letters only ('a..f').
Choosing correct prediction is the most essential in the way that will minimize the risk of skipping the right solution.

Such as guessing that not only there will be at least some letters ('a..f'), but also how much of those, will there be at least one letter, two letters, three letters?
Will be some letters repeated? Or next to each other, such as 'FF' or 'AA', or in-between 'letter-number-letter', 'letter-letter-number-number' somewhere in private key hexadecimal string, etc.
Same for numbers.

Ruling out key candidates like that results in hardware computational speed-ups that are tens, hundreds or even thousands multiplies of the original speed of the device, but naturally depending on parameters greatly increase risk of skipping the right solution.
This is of course primitive approach just for sake of example.

I went further with it and made approach tunable by far more advanced parameters, probability and combination of prediction systems that resulted in significant speed-up per hardware device, but is keeping it in relatively safe area for risk of skipping the right solution.
Safety and approach being tunable to reach right balance between risk and speed-up.

It is definitely far more fun than plain brute-force of one-by-one scanhashing and much more effective when keeping within safe parameters.

Btw. I effectively implemented the same method to cryptocurrency mining in various mining algorithms where my mining kernels by fine-tuning probability using prediction systems approach algorithmically manipulate chances, move chances of finding nonce to miner side, skipping non-interesting nonce candidates without any hashing at all giving miner the house edge, fine-tuneable to balance risk and the right solution.

That results in nonce being found more often in contrast to old-fashioned one-by-one scanhash brute-force mining, thus overall faster miner, how faster depending on internal fine-tuning.

Bruteforce mining one-by-one scanhash is sooooooo boring, 'prediction mining' and skipping nonce candidates without hashing is fully according to my taste.
But well that is another story.

Funny, I do this all the time, running two instances of the same miner program, at the same time, on the same hardware, both instances using the same GPUs, with different algorithm settings and intensities.
One algorithm memory heavy the other one core heavy, both mining to my own wallets and in the end I make more when those incomes are added together, than if I was just mining single algorithm with only one single miner instance.

I really don’t care whether those two instances are "fighting", as you say, or whether they "like" it or not, or what they do.
All I care is that my rig is running rock stable and in the end I make more – that's what matters to me when mining.

But of course everyone is free to do what he believes is best for him and his rig.

The simpliest way is to run 2 instances of mining program. One with high intensity the other one with very low intensity, each mining to it's own/different address all the time.
Miner with low enough intensity will not eat much hashrates from the miner with high intensity, so the one with low intensity can be actually considered "custom devfee".

Doing it this way can be actually even better and more profitable than letting miner to switch addresses every hour or so.

Btw. depending on algorithms and settings, sometimes running two instances of miner program on the same hardware can be even more profitable – the algorithms will not eat much hashrates from each other, if any! So when those hashrates are added together they can be even higher and more profitable in the end!
Hence, that's probably the way how Claymore came to it, that it can be more profitable to run two instances/threads on the same rig.

It works even with any regular single miners. Just run two instances of your favorite miner on the same rig with various algorithms at the same time and see.
If one algorithm is memory heavy and the other one is core heavy, the resulting profitability will be higher in the end when income is added together.  

Nice benchmark website, but I am missing intensity and other parameters, such as launch config for CryptoNight and other setup data of respective miners used for benchmarking.
Those pareameters are also very important and can have huge influence on resulting hashrate and that's why they should be definitely shown near every benchmark on your website.

Every single leaked/stolen sp_ miner put to open contains (real) trojan! So beware using those otherwise that 20% "improvement" can be in fact very pricey at the end.
Only those sp_ miners that are purchased by a donation directly to sp_ are safe to use!

Unfortunately, there is no universal sweet spot. Every single card and every single mining algorithm is different and thus reacts differently to various OC settings.

You must experiment and find best OC settings by yourself.
Please also keep in mind that sweet OC spot is different per every single mining algorithm, so every time you switch mining algorithm you should also change OC settings of your cards for best possible performance!

Try to physically swap/mix order of those cards in risers on motherboard to see whether problem will be reported on the exactly same GPU or different one.
This way you will see if it is hardware failure of GPU, or riser failure, or software driver problem.

If you are mining on Windows 64-bit version best free skunk miner is tpruvot's ccminer 2.2, 32-bit, x86 version.
It is about 5% faster than x64 – that's deference of about 3MH/s, just by running/compiling x86!

Also more hashes can be achieved fine-tuning miner intensity to decimal numbers, until you reach best results for your setup.
Try it, go by really really small decimal steps for intensity, it can make some pretty BIG differences.

I found out that for me intensity of 21.0956 makes difference of about 1-2MH/s more per every single 1080 Ti compared to default skunk intensity of 21!
But when I set intensity to higher than that, my skunk hashing speeds just go slightly down from there.
Simply for me intensity of 21.0956 is the best possible maximum for skunk algorithm.

I mean intensity of 21.0956 mining skunk in tpruvot's ccminer 2.2, 32-bit, x86 version gives me about 59MH/s, sometimes it jumps even little bit over 60MH/s per 1080 Ti card in contrast to plain default intensity of 21 which gives just about 2MH/s less with the same OC settings. I described my OC settings some posts ago.
Skunk hashes on my Aorus 1080 Ti Xtremes faster with overclocking/underclocking at core +120 (1841MHz) and memory -2000 (9010MHz) with power limit at 85%.

Also compiling tpruvot's ccminer 2.2 with CUDA 9 gives a little bit better performance.

What good is a screenshot if there is a page that is far better than simple screenshot:
http://yiimp.ccminer.org/bench?algo=neoscrypt&chip=387

On there you can see realtime benchmarks of mining 1080 Tis, including their clocks, exact miner version and other infos.
As you can see they are running around 1.6 MH/s at neoscrypt in tpruvot's ccminer 2.2 and that is really about 30% boost compared to 1070, so Schleicher is right.

I use Aorus native utility called "GRAPHICS ENGINE" for overclocking/underclocking.
I am not sure whether that tool would work also for 1080 Tis of other brands and manufacturers, but probably not.  

Skunk algorithm is pretty sensitive for overclocking/underclocking of 1080 Ti in a good and most efficient power consumption way for me.

I overclocked /underclocked my Aorus 1080 Ti Xtremes to core +120 (1841MHz) and memory -2000 (9010MHz) with power limit at 85% and getting around 59 MH/s in tpruvot's ccminer x86 2.2 per every single card!

It seems that lowering memory clocks to lowest possible value helps gaining hashes in this specific algorithm.

For example at stock settings (1721MHz / 11010MHz) and power limit at 100% these Aorus 1080 Ti Xtreme cards are giving only about 52 MH/s per card in the same miner with each card pulling 100W more of the wall in contrast that when they are actually underclocked to settings I described, pulling 100W less of the wall per each card, yet still running about 7 MH/s more per card at skunk!

I guess it is because of GDDR5X memory types these cards have and that's why lowering memory clocks a lot surprisingly gains more hashes at these cards.