I have attempted a similar approach before and my understanding goes as follows:

1) While it's easy to mathematically count how many of those values we are filtering out, it's quite hard to filter out those values and only check keys that fall out of the rules you put in place efficiently, the scanning process overall could be faster as essentially you are skipping ECC on a ton of keys but having to perform a check on every single value sequentially to check if it should be filtered out is additional operations, the key space is still too big and the chances you have of finding the correct key for the puzzle are now lower as you are skipping keys

2) Looking at keys from previous puzzles may give a sentiment of "no 3 of the same consecutive hex characters appear often in the solved puzzles" that seems to be true for low bit entropy puzzles but it's meaningless, unless there was bias or a flawed way to randomize these keys when the puzzle was created, any value has the exact same chance of being the correct key even if it looks like 50000000000000000a

I have tried to scan the range and filter out keys that followed specific rules like "no 4 of the same consecutive hex characters (aaaa,bbbb,ffff etc...)" or "no 3+2 consecutive pairs (aaa00, fff22 etc...)" but with limited computing even performing this filtering would still take a huge amount of time, for reference I used an RTX 4090 and a Ryzen 9 9950x3d and it's just not enough for a range this big, it would still take years.

By no means I want to discredit your method, this is just my experience but I encourage you to experiment and who knows maybe you get lucky, but filtering out values in an efficient manner is quite the challenge especially when you want to optimize for parallelization 

For old wallets (2009-2017) there is not much to do beside having "performance counter data" which can lead to guessing private keys.

If you have this old perfdata you can generate old private keys and take the balance.

Seems like the only way to steal funds from these old addresses.

Okay, can you give an example?!

Well, this is all clear))

I have this question for you.
Let's say I found a key that I use as point G.
Using this, I add 1 to my search key, and I also subtract 1 to my search key. As a result, I get the same public key, one is 03 and the other is 02.

Is it possible in this case to calculate the private key I am looking for?

As far as I remember, by changing point G, as a result, we no longer add and subtract, but divide and multiply our public key? Or I was mistaken. Just knowing this, it seems to me that you can calculate the difference.

So are you accusing the puzzle creator of theft? Meaning he will later empty other people's wallets?

Here is another embarrassment for all the so called educated people, my post above, if you can, go ahead and solve it. 😂

I sometimes think that the creator has been withdrawing the BTC from the undisclosed wallets in recent years, I see no reason why someone who unlocks the puzzle should not share their keys anonymously once the wallet is emptied, either that or there is a possible sequence that we are not seeing.

What is 68719476736 , why this number and how you calculated it?

I have ~90 Ekeys/s in BSGS/keyhunt

Hey Guys i have a question.. well lets say we subtract a target public key puzzle (130) using key subtractor with 1000000000000000000000000000 continuously at some point it movies from the additive inverse to the negative inverse right? are there any ways we could possible know at what point the reset point happened ?