Bitcoin puzzle transaction ~32 BTC prize to who solves it

[nomachine]

how to edit for adress 19vkiEajfhuZ8bs8Zu2jgmC6oqZbWqhxhG in WIFHunter.py

All the commands can be found here:
https://github.com/iceland2k14/secp256k1

Code:

       
                HEX = ice.btc_wif_to_pvk_hex(message)
                dec = int(HEX, 16)
                addc = ice.privatekey_to_address(0, True, dec)
                addu = ice.privatekey_to_address(0, False, dec)
                target_add = "19vkiEajfhuZ8bs8Zu2jgmC6oqZbWqhxhG" 
                if addc == target_add or addu == target_add:

[Akito S. M. Hosana]

Code:

python3 WIFHunter.py 
[2025-04-18 13:09:13]  Starting scan for prefix: KyNuLW
[2025-04-18 13:09:13]  WIF Hunter

How long does it take for the script to run through

if "KxFyGD" <= prefix < "L5oLmv"

 

[nomachine]

How long does it take for the script to run through

if "KxFyGD" <= prefix < "L5oLmv"

 

The range includes all Base58 strings starting from "KxFyGD" up to (but not including) "L5oLmv". The total number of combinations is: 5852906891

If you have a script that solves one prefix in a second - 185.6 years

[Akito S. M. Hosana]

If you have a script that solves one prefix in a second - 185.6 years

Sorry for even asking. 

[Desyationer]

It seems I managed to run wifhunter on win11, 5800x3d shows the following speed, it is interesting to compare with other processors.

Code:

[2025-04-18 16:00:55] [I] Starting scan for prefix: L5FNHG
[2025-04-18 16:00:55] [I] WIF Hunter
[2025-04-18 16:00:55] [I] CHECKING WIF PREFIX KwDiBf:
[2025-04-18 16:01:06] [I] Progress = 0.43 % [16.26 Mkeys/sec]
[2025-04-18 16:01:18] [I] Progress = 0.86 % [16.24 Mkeys/sec]
[2025-04-18 16:01:30] [I] Progress = 1.29 % [14.86 Mkeys/sec]
[2025-04-18 16:01:41] [I] Progress = 1.72 % [15.50 Mkeys/sec]
[2025-04-18 16:01:53] [I] Progress = 2.16 % [15.08 Mkeys/sec]
[2025-04-18 16:02:05] [I] Progress = 2.59 % [15.70 Mkeys/sec]
[2025-04-18 16:02:17] [I] Progress = 3.02 % [15.60 Mkeys/sec]
[2025-04-18 16:02:28] [I] Progress = 3.45 % [15.64 Mkeys/sec]
[2025-04-18 16:02:31] [W] KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn
Found matching private key!
[2025-04-18 16:02:31] [i] PRIVATE KEY FOUND!!!
[2025-04-18 16:02:31] Compressed HASH160: 751e76e8199196d454941c45d1b3a323f1433bd6
[2025-04-18 16:02:31] Uncompressed HASH160: 91b24bf9f5288532960ac687abb035127b1d28a5
[2025-04-18 16:02:31] Private key (hex): 0000000000000000000000000000000000000000000000000000000000000001
[2025-04-18 16:02:31] Private key (decimal): 1
[2025-04-18 16:02:31] [I] Private key saved to C:\Users\hexap\Downloads\WIFHunter-main\reports\found_key.txt
[2025-04-18 16:02:31] [i] Script execution ended

[nomachine]

it is interesting to compare with other processors.

Later, I will upgrade GIT with an even faster variant of Base58 decoding—but not the one Akito thinks I will (using AVX2 SIMD instructions). 

[Akito S. M. Hosana]

but not the one Akito thinks I will (using AVX2 SIMD instructions). 

I see that it has been upgraded. This isn't just a bit faster — it's twice as fast now. And it's still using scalar (1x) base58 decoding 

[hotmoney]

Parece que consegui executar o wifhunter no win11, 5800x3d mostra a seguinte velocidade, é interessante comparar com outros processadores.
Código:

[2025-04-18 16:00:55] Inserção da varredura para prefixação para o prefixo: L5FNHG
[2025-04-18 16:00:55] WIF Hunter
[2025-04-18 16:00:55] CHECKING WIF PREFIX KwDiBf:
[2025-04-18 16:01:06] Progresso - 0.43 % [16,26 Mkeys/sec]
[2025-04-18 16:01:18] Progresso - 0,86 % [16,24 Mkeys/sec]
[2025-04-18 16:01:30] Progresso - 1,29 % [14,86 Mkeys/sec]
[2025-04-18 16:01:41] Progresso ? 1.72 % [15,50 Mkeys/sec]
[2025-04-18 16:01:53] Progresso ? 2.116 % [15.08 Mkeys/sec]
[2025-04-18 16:02:05] Progresso - 2.59 % [15,70 Mkeys/sec]
[2025-04-18 16:02:17] Progresso - 3,02 % [15,60 Mkeys/sec]
[2025-04-18 16:02:28] Progresso - 3,45 % [15,64 Mkeys/sec]
[2025-04-18 16:02:31] [W] KwDiBB89QggGbjEhKnhXJuH7LrZiZi3Yjgd9M7rFU73sVHnoWn
Encontrado combinando chave privada!
[2025-04-18 16:02:31] FOUND PRIVADO DE CHAVE!!!
[2025-04-18 16:02:31] Comprimido HASH160: 751e76e819899966494941c45d1b3a323f1433bd6
[2025-04-18 16:02:31] HASH160 descompactado: 91b24bf9f5252532960ac687abr
[2025-04-18 16:02:31] Chave privada (hex): 00000000000000000000000000000000000000000000000000000000000000000001
[2025-04-18 16:02:31] Chave privada (decimal): 1
[2025-04-18 16:02:31] Chave privada salva para C:?Users?hexap?Downloads?WIFHunter-mainr?reports?found_key.txt
[2025-04-18 16:02:31] Emissão escrita terminou


knife right away for puzzle 69 instead of 1

[nomachine]

but not the one Akito thinks I will (using AVX2 SIMD instructions). 

I see that it has been upgraded. This isn't just a bit faster — it's twice as fast now. And it's still using scalar (1x) base58 decoding 

No matter how fast it is, it's not enough. I told you in the previous post—you need to process thousands of prefixes per second, not one per minute. 

[kTimesG]

How could I take them seriously and make a proposal on equal terms in the pursuit of truth if I receive childish responses?

I don’t have as much time as you do; I work, and I don’t have a PC that can run quick tests.

I don’t want to waste time making scripts that won’t provide anything beyond childish things.

I never heard you thanking Bram for taking from his own time to even test your theory, even if it is not to your taste for various reasons.

You talk about scientific methods and so on, but you can't even test your own theories (let alone prove them), however you are so sure that they are working and are fail-safe, to the point of comparing yourself to the greatest minds in history vs clueless peasants. You know, all the guys with PhDs and so on, who refuted the Monty Python issue, they all later apologized, after being shown the proof of truth. In this case (you vs whomever), even after having all the proofs contrary to what you believe, the proofs will never ever suffice to make you even consider the fact that you might, at the end of the day, be wrong.

So, it's understandable why you don't want to waste time writing scripts. After all, you very well know that if what you suggest is true, it would mean cryptography is broken. Thank you for not wanting to prove us that cryptography is broken.

[nomachine]

knife right away for puzzle 69 instead of 1

Nah, not like that, amigo… I’d be down for that too. But for puzzle 69, you need the end of the WIF, not the beginning. And you gotta hit 19 characters. If we're only pulling 3500 MWIFs per second, it ain’t happening…

[Bram24732]

I created a script under the worst possible conditions for prefix searching (intentionally). Even so, if you run several tests, you'll see that the prefix search achieves the same frequency of success as yours in this particular case, though you only publish instances where your method wins.

You might have missed my point.
I'm not saying my method "wins". I'm saying that on average prefix theories have EXACTLY the same speed as a linear search. Which this script demonstrates beautifully.

How could I take them seriously and make a proposal on equal terms in the pursuit of truth if I receive childish responses?

I don't see what was childish about my response. As I told you I'm very happy to make this script evolve until you can be convinced that prefixes do not provide a speedup over linear.

The only thing that matters is reaching the truth under correct conditions, right?

Exactly, so let's reach the truth.
You dont need a fast PC to run the script, I can do that on my end.

[Akito S. M. Hosana]

If we're only pulling 3500 MWIFs per second, it ain’t happening…

Man, I don’t get any of this now… but hey, I found what I came for—one big ol’ nothing 

[WanderingPhilospher]

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 think you have my style confused with Bibli's style.

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.

I'm not saying my method "wins". I'm saying that on average prefix theories have EXACTLY the same speed as a linear search. Which this script demonstrates beautifully.

My only issue with this statement, is that you and ktimes have chit all over h160 partial matches, and anyone who says anything about a prefix lol, saying they are useless. At worse, they divide the range up differently than what you are doing, range / x = y subranges.

[Bram24732]

I'm not saying my method "wins". I'm saying that on average prefix theories have EXACTLY the same speed as a linear search. Which this script demonstrates beautifully.

My only issue with this statement, is that you and ktimes have chit all over h160 partial matches, and anyone who says anything about a prefix lol, saying they are useless. At worse, they divide the range up differently than what you are doing, range / x = y subranges.

Let's clarify what I mean by useless : They do not provide a statistical edge over a linear search, but makes the code you have to write more complex, and potentially not GPU friendly.  It's only drawbacks in my opinion.
Appologies if anyone thought they were shat on. My intention was not to hurt but to let people know there is no magic statistical edge there.

[kTimesG]

I'm not saying my method "wins". I'm saying that on average prefix theories have EXACTLY the same speed as a linear search. Which this script demonstrates beautifully.

My only issue with this statement, is that you and ktimes have chit all over h160 partial matches, and anyone who says anything about a prefix lol, saying they are useless. At worse, they divide the range up differently than what you are doing, range / x = y subranges.

Hmmm... but how can something that does not add any value in any way be called something else than "useless"?

If I find some hash that has 67 matching bits with the target hash (67 front bits, or 67 tail bits, or some whatever 67 bits matched in some combination of 67 out of 160 positions I want to pick), then whom/what/why/how does that influence in any way the probability of the next key that I'll check (be it k + 1 or some other k), to NOT have all the 160 bits of the target hash matching?

What if I find 159 matched bits out of 160? Is it impossible, or just very unlikely?

If we struggle hard enough, we can find these sort of "unlikely" things for any two hashes we ever pick, resulting in excluding basically all the keys or ranges as a viable candidate for the next key to check.

[WanderingPhilospher]

I'm not saying my method "wins". I'm saying that on average prefix theories have EXACTLY the same speed as a linear search. Which this script demonstrates beautifully.

My only issue with this statement, is that you and ktimes have chit all over h160 partial matches, and anyone who says anything about a prefix lol, saying they are useless. At worse, they divide the range up differently than what you are doing, range / x = y subranges.

Let's clarify what I mean by useless : They do not provide a statistical edge over a linear search, but makes the code you have to write more complex, and potentially not GPU friendly.  It's only drawbacks in my opinion.
Appologies if anyone thought they were shat on. My intention was not to hurt but to let people know there is no magic statistical edge there.

Lol, more complex and not GPU friendly? How so? I bet my entire code, search program, client, and server, is just as friendly, if not more, than yours. You obviously have something built into yours to find PoW h160 matches, but for 67, it was a whole different h160 than the target key; nothing right or wrong with that. Mine simply checks for x matching h160 characters of the target key provided.
And I believe if you read back, a few already agreed/stated, there was no magic statistical edge. (Can't speak for Bibil though lol)

Hmmm... but how can something that does not add any value in any way be called something else than "useless"?

Come on ktimesG, that statement is windier than a sackful of farts lol.
Does selecting random subranges, then searching sequential in that subrange, add any value over starting at the beginning key of the entire range and searching until the last key of the range? Oh sure, bend it like you all did before saying, uhhhh your competition will know what you are doing and just start somewhere else or at the opposite end, etc. But no one knows what anyone is doing, other than a public pool. Bram does not disclose his current stats anywhere, publicly. So I guess random subranges is useless too lol.

If I find some hash that has 67 matching bits with the target hash (67 front bits, or 67 tail bits, or some whatever 67 bits matched in some combination of 67 out of 160 positions I want to pick), then whom/what/why/how does that influence in any way the probability of the next key that I'll check (be it k + 1 or some other k), to NOT have all the 160 bits of the target hash matching?

Stats, data, tests, tell me that it is 99.99999999999% not gonna happen lol. Run the public data that Bram provided for his PoW keys. How many were back to back in sequential order? Stop beating this dead horse. It's a risk/reward. For the 69 puzzle (in a 68 bit range), you would find maybe 2 h160 matches with 67 matched bits, in sequential order. Pretty small chance that it would be the actual h160 I am looking for. A risk I would definitely take 7 times each day and 45 times on Tuesday.

[Bram24732]

Lol, more complex and not GPU friendly? How so? I bet my entire code, search program, client, and server, is just as friendly, if not more, than yours.

Let's not make this into a contest, I couldn't care less who writes the friendliest code.
Besides mine is in assembly so likely not friendly at all to most people.

I was not refering to how to collect prefixes, that's exactly the same code as how I collect pow proofs, and is dead simple in any case.
I was talking about any strategy to use those prefixes. They are by definition more complex than linearly scanning a range. GPUs typically don't handle sparse seach spaces efficiently for instance.

[kTimesG]

Hmmm... but how can something that does not add any value in any way be called something else than "useless"?

Come on ktimesG, that statement is windier than a sackful of farts lol.
Does selecting random subranges, then searching sequential in that subrange, add any value over starting at the beginning key of the entire range and searching until the last key of the range?

Of course it doesn't really matter HOW you pick the subranges to scan. This is the entire point. The sequential scan speed-up was probably understood wrong: it was about not skipping individual keys, and doing a full start-end subrange scan, not about what subrange you intend to scan. That is a totally personal preference that does not help or interfere with anything.

Since each worker needs to start from some point, obviously it does not matter from what point it starts from - all ranges are totally equal. So choosing sequential ranges or not is the same thing, since I don't see any way to speed up the initial setup, especially when dealing with tens / hundreds of parallel workers.

Stats, data, tests, tell me that it is 99.99999999999% not gonna happen lol. Run the public data that Bram provided for his PoW keys. How many were back to back in sequential order? Stop beating this dead horse. It's a risk/reward. For the 69 puzzle (in a 68 bit range), you would find maybe 2 h160 matches with 67 matched bits, in sequential order. Pretty small chance that it would be the actual h160 I am looking for. A risk I would definitely take 7 times each day and 45 times on Tuesday.

It's also 99.9999999...% not gonna happen no matter what key you choose next, either if it's the k + 1 or some other key in some other range. There is no disagreement here.

[WanderingPhilospher]

Lol, more complex and not GPU friendly? How so? I bet my entire code, search program, client, and server, is just as friendly, if not more, than yours.

Let's not make this into a contest, I couldn't care less who writes the friendliest code.
Besides mine is in assembly so likely not friendly at all to most people.

I was not refering to how to collect prefixes, that's exactly the same code as how I collect pow proofs, and is dead simple in any case.
I was talking about any strategy to use those prefixes. They are by definition more complex than linearly scanning a range. GPUs typically don't handle sparse seach spaces efficiently for instance.

The initial (and any follow up) searching for matching 160s, is easy. The collection of and the use of. It is automatic once a partial h160 match is found. Automatic as in setting the padding and entering that range into the db. There is no sparse searching in any space.

You do your db setup up front, with, range / x = y subranges. I let the found partial matches set my initial ranges. And now, I can bounce around with random or gap, each, starting at x and checking to y. This is a test that should be ran lol. ranges ending with ..000000 + whatever search size, or random endings, other than ...0000. I am sure it would all come out in the wash, but would be interesting to test.

Also, my setup allows the easy "do not check, highly unlikely ranges". For example, ranges starting with the same character, 3 or 4 or 5 (whatever filter you want to apply); meaning a range like 0x2222xxxxxxxxxxx - 0x2223xxxxxxxxxxx would not be checked (if your filter said not to check 4+ same characters in a row). I know people will argue over that as well, but to me, that is a range easy to omit in the initial search. Always easy to remove it and allow it to be checked if the other 99.5% keys did not find the winning key. And my setup allows for CPUs to get into the mix; no, they aren't searching as much as the GPUs, but if you have thousands of cores available, why would you not use them, right? Every key searched helps, regardless of the equipment used

But let's be real, it all comes down to firepower. On average, those with the most, will find the key first. Unless someone is really really lucky lol.

ktimesg, did you see the partial match found late last night/early this morn: 19vkiEajfhu8gnX5QUJZReqALvkTncJtgu

Not gonna lie, I had to do a double take because of that 8. I knew an 8 was close after the u lol.