Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Bram24732]

so you were going to prove that I was wrong, someday?

The arrogance is astounding.
You probably have to chage 20 or so lines of code to accomodate the script to your theory and run it by yourself, but you wont.
If this does not change your mind, nothing will and I wish you all the best.

20 lines, lol, I just want to make it clear that you shouldn't criticize without knowing. I don't criticize anyone's ideas here, so why would you come and criticize mine? If it's 20 lines, why didn't you do it? That was your main purpose, wasn't it?

I did not do it because it will never be good enough to convince you. I realize that now.
If it shows no improvement over random, you'll say it's because its numbers and not private keys..
if I change it to be private keys and your method, you'll find another way to dismiss it, and so on.
To be honest I'm quite sure you didn't bother reading it or running it. So well, you win this argument Enjoy !

You have just exposed yourself. First, it makes no sense with any of the methods discussed here. Second, where are the hashes in your test? You skipped the fundamental part of the theories here: uniform distribution of the hashes. Without hashes, there is no uniform distribution, so your script is meaningless. Lol.

Oh damn this is gold

[xtrymm]

#Has anyone ever searched for hidden messages within hashes?

import base58

addr = '18bsqCiFJRy6iLQuomV9uQWuJG2TCzkK3h' 
h160 = base58.b58decode_check(addr)[1:]
print (h160)

addr = '1Ax1Ske5KLG8NuBbhVQ3594DViop8RMPUC' 
h160 = base58.b58decode_check(addr)[1:]
print (h160)

addr = '1BX5TLkQe5YEHYfQAFXEKnWgVmqTSGZhsF' 
h160 = base58.b58decode_check(addr)[1:]
print (h160)

Sounds like a cool idea but I think it would be unfeasible for the creator to search the entire keyspace of bitcoin and cherry pick h160 to create some sort of code, as far as my understanding goes (please correct me if I am wrong) the creator generated a fixed number of keys and padded each key with zeroes to make them "fit" within a lower bit entropy, using some sort of code that could give hints to speed up the process of "unlocking" those puzzles, would defeat the purpose of this puzzle "simply a crude measuring instrument of the cracking strength of the community"

Not to ruin anyone's hopes and dreams, but I believe that the only ways to crack these puzzles are sheer computing power or an insane amount of dumb luck, maybe one day someone finds a flaw in ECC but if that day was ever to come... most crypto would immediately tank to 0

[farou9]

The pubkey is there so the private key can be found in a few seconds.

How?

000000000000000000000000000000000000000000000017724AFA4320DAF4A7

He assumed the address was within 69.

Good morning, but how did you get the private key for address 19vkiEajfhnHnZjGpogP6Rv8sUQFvF7PiS, having only the public key?

He used Kangaroo method or bsgs

[kTimesG]

https://en.wikipedia.org/wiki/Denialism

https://en.wikipedia.org/wiki/Motivated_reasoning

https://en.wikipedia.org/wiki/Confirmation_bias

Biased search for information, biased interpretation of this information and biased memory recall, have been invoked to explain four specific effects:

- attitude polarization (when a disagreement becomes more extreme even though the different parties are exposed to the same evidence)
- belief perseverance (when beliefs persist after the evidence for them is shown to be false)
- the irrational primacy effect (a greater reliance on information encountered early in a series)
- illusory correlation (when people falsely perceive an association between two events or situations).

Irrational rejection of proof

In mathematics, “evidence” takes the form of proofs rather than experiments. Refusing to accept a valid proof for, say, 1 + 1 = 2 or the Pythagorean theorem is still a refusal to concede well‑established reasoning.

It typically reflects motivated reasoning: you dismiss the logical steps because they conflict with some personal belief, agenda, or emotional need.

Cognitive biases in pure thought

Confirmation bias: cherry‐picking or inventing “counter‑examples” that aren’t valid.

Dunning–Kruger effect: overestimating one’s own understanding of advanced math, leading to unwarranted confidence in rejecting proofs.

When it crosses into pathology

A stubborn but isolated refusal to accept math truths—while odd—doesn’t by itself constitute a mental disorder.

However, if it’s part of a broader pattern of fixed, false beliefs resistant to any amount of logical or empirical correction, it may signal a delusional disorder or schizotypal/paranoid personality features. In clinical terms, a person truly convinced that 2 + 2 = 5 despite flawless proofs might be considered delusional.

Refusing pure‑logic proofs without any logical flaw is best viewed as a form of denialism or motivated reasoning. If it’s pervasive and part of a wider pattern of unshakable false beliefs, it may meet criteria for a delusional or paranoid condition—but otherwise it remains an extreme cognitive bias rather than a standalone “math disorder.”

[Bram24732]

https://en.wikipedia.org/wiki/Denialism

https://en.wikipedia.org/wiki/Motivated_reasoning

https://en.wikipedia.org/wiki/Confirmation_bias

Biased search for information, biased interpretation of this information and biased memory recall, have been invoked to explain four specific effects:

- attitude polarization (when a disagreement becomes more extreme even though the different parties are exposed to the same evidence)
- belief perseverance (when beliefs persist after the evidence for them is shown to be false)
- the irrational primacy effect (a greater reliance on information encountered early in a series)
- illusory correlation (when people falsely perceive an association between two events or situations).

Irrational rejection of proof

In mathematics, “evidence” takes the form of proofs rather than experiments. Refusing to accept a valid proof for, say, 1 + 1 = 2 or the Pythagorean theorem is still a refusal to concede well‑established reasoning.

It typically reflects motivated reasoning: you dismiss the logical steps because they conflict with some personal belief, agenda, or emotional need.

Cognitive biases in pure thought

Confirmation bias: cherry‐picking or inventing “counter‑examples” that aren’t valid.

Dunning–Kruger effect: overestimating one’s own understanding of advanced math, leading to unwarranted confidence in rejecting proofs.

When it crosses into pathology

A stubborn but isolated refusal to accept math truths—while odd—doesn’t by itself constitute a mental disorder.

However, if it’s part of a broader pattern of fixed, false beliefs resistant to any amount of logical or empirical correction, it may signal a delusional disorder or schizotypal/paranoid personality features. In clinical terms, a person truly convinced that 2 + 2 = 5 despite flawless proofs might be considered delusional.

Refusing pure‑logic proofs without any logical flaw is best viewed as a form of denialism or motivated reasoning. If it’s pervasive and part of a wider pattern of unshakable false beliefs, it may meet criteria for a delusional or paranoid condition—but otherwise it remains an extreme cognitive bias rather than a standalone “math disorder.”

Someone graduated from "sucking at math" to "full on schizo" in someone's book it seems

[kTimesG]

...

Someone graduated from "sucking at math" to "full on schizo" in someone's book it seems

Most often, people sucking at math admit it way before we even attempt to start explaining things. I like those kind of people, though it's sad they' ll never be able to enjoy knowing the awesome things we want to share with them.

[Akito S. M. Hosana]

But what are you going to do with it?

I need a script that can recover the beginning of a WIF where some characters are missing — for example, WIF500, etc  

[nomachine]

But what are you going to do with it?

I need a script that can recover the beginning of a WIF where some characters are missing — for example, WIF500, etc  

Such a script is more complex than the previous one because you need to calculate the checksum for each WIF individually. I already have something similar in my archive, but it needs to be updated to use AVX2 hashing. I’ll upload it to GitHub. I don't know when.

[WanderingPhilospher]

so you were going to prove that I was wrong, someday?

The arrogance is astounding.
You probably have to chage 20 or so lines of code to accomodate the script to your theory and run it by yourself, but you wont.
If this does not change your mind, nothing will and I wish you all the best.

20 lines, lol, I just want to make it clear that you shouldn't criticize without knowing. I don't criticize anyone's ideas here, so why would you come and criticize mine? If it's 20 lines, why didn't you do it? That was your main purpose, wasn't it?

I did not do it because it will never be good enough to convince you. I realize that now.
If it shows no improvement over random, you'll say it's because its numbers and not private keys..
if I change it to be private keys and your method, you'll find another way to dismiss it, and so on.
To be honest I'm quite sure you didn't bother reading it or running it. So well, you win this argument Enjoy !

You have just exposed yourself. First, it makes no sense with any of the methods discussed here. Second, where are the hashes in your test? You skipped the fundamental part of the theories here: uniform distribution of the hashes. Without hashes, there is no uniform distribution, so your script is meaningless. Lol.

I will have to think about all of what has been said and look at Bram's script and how it was used, before I can give a quality answer on it all. However, my initial thoughts with prefix padding then searching (random then sequential) versus random then sequential are a wash. Can one find lightning in a bottle by using prefixes (in whatever way, skipping keys, padding, etc.), YES.
Could Bram find the key in the first random block he/his program chooses to search, YES! But for both, the averages, tell us a different story...50% on average. So yes, both could find the key within the first minute of searching, and sometimes it may be the last possible range to search...but the averages, smooth out over x amount of tests.
Now, I say this, about the averages, but I also believe it to be true about h160 matching characters (bits) as I have seen in running numerous tests. People should not talk about averages in one way, but neglect to mention them/think about them in another way. Sometimes, I forget about one side or the other as well, so yes, I am at fault too.

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. Instead of just taking a range and dividing it by x, and then searching one of those ranges, I like the way I am doing it now, based off of h160 matches and averages. Will it solver faster? Only if I one can narrow down the paddings...narrow, may not be the right word...more like, create the largest "gap" in between found found h160 matches, without going over...maybe I should call it the H160 Matching Showcase Showdown, method...LOL. So in summary, I think ktimeG, Bram, Bibli, and McDouglas are all correct, just in different things lol.

Back to dirt and mulch...

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

[bibilgin]

up.. cut..

Here is the summary of your character;

Making fun,
Changing the subject,
Deserving insults. lol

You didn't say what you thought about John. You made fun of him. So you deserve to be insulted.

Now useless kid (old kid) go get lost. lol
You're not worth wasting my time with your dishonest answers.

I don't understand what you're saying I'm sorry.

The question you asked has 2 perspectives.

Reality = Where John lives is the situation as it really is. In other words, if John really lives in Türkiye, this situation reflects a reality in the outside world and this reality exists independently.

Knowledge = Saying "where John lives" is valid if the reality is where he lives. But it does not change where John really lives right now.

I don't know which answer will make you happy.

Here, we don't need to confuse many people in a philosophical, ontological, epistemological cycle. It is enough to tell the answer to the question I asked and which method you will use.

There was an article that I mentioned before and you also mentioned.

I = Every brave man eats yogurt differently.
You = We all have different learning/understanding abilities.

Bram, do you understand now? If so, I'm still waiting for your answer. What would you do to find JOHN?

[kTimesG]

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?

[hotmoney]

Guys, in my opinion I believe in the prefixes next and a half today I found 5 and they were very close

19vkiEajfh uZ8bs8Zu2jgmC6oqZbWqhxhG 69 /6.9 btc

19vkiEajfh 8asnMYgN8qfm1kM4Gk5AssNR

19vkiEajfh mfv7LN32tQB8373k8P56ZdRX


19vkiEaj uiCNKC6dVeXN15dpRnANF5rHch


19vkiEaj DnQKG83Eibm7TA97TkTNrY9uGQ

19vkiEaj HXf1kuKy1iFFVEp8stKzpA28SK

For me personally it might be fun... if it doesn't have any mathematical basis, but for me it might be cool.

[nomachine]

But what are you going to do with it?

I need a script that can recover the beginning of a WIF where some characters are missing — for example, WIF500, etc  

https://github.com/NoMachine1/WIFHunter

There's no manual for this. If you can't figure out how it works on your own, then you don't need the script. 

[Akito S. M. Hosana]

But what are you going to do with it?

I need a script that can recover the beginning of a WIF where some characters are missing — for example, WIF500, etc  

https://github.com/NoMachine1/WIFHunter

There's no manual for this. If you can't figure out how it works on your own, then you don't need the script. 

[2025-04-17 22:16:17] Progress = 59.66 % [10.39 Mkeys/sec]
[2025-04-17 22:16:30] Progress = 60.00 % [10.47 Mkeys/sec]
[2025-04-17 22:16:43] Progress = 60.34 % [10.47 Mkeys/sec]
[2025-04-17 22:16:56] Progress = 60.69 % [10.43 Mkeys/sec]
[2025-04-17 22:17:09] Progress = 61.03 % [10.45 Mkeys/sec]
[2025-04-17 22:17:22] Progress = 61.38 % [10.44 Mkeys/sec]
[2025-04-17 22:17:35] Progress = 61.72 % [10.41 Mkeys/sec]
[2025-04-17 22:17:48] Progress = 62.07 % [10.42 Mkeys/sec]
[2025-04-17 22:18:01] Progress = 62.41 % [10.42 Mkeys/sec]
[2025-04-17 22:18:14] Progress = 62.76 % [10.47 Mkeys/sec]
[2025-04-17 22:18:16] [W] KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn
Found matching private key!
[2025-04-17 22:18:16] PRIVATE KEY FOUND!!!
[2025-04-17 22:18:16] Compressed HASH160: 751e76e8199196d454941c45d1b3a323f1433bd6
[2025-04-17 22:18:16] Uncompressed HASH160: 91b24bf9f5288532960ac687abb035127b1d28a5
[2025-04-17 22:18:16] Private key (hex): 0000000000000000000000000000000000000000000000000000000000000001
[2025-04-17 22:18:16] Private key (decimal): 1
[2025-04-17 22:18:16] Private key saved to /Desktop/WIFHunter/reports/found_key.txt
[2025-04-17 22:18:16] Script execution ended

I just solved puzzle 1 

[viceversas]

But what are you going to do with it?

I need a script that can recover the beginning of a WIF where some characters are missing — for example, WIF500, etc  

https://github.com/NoMachine1/WIFHunter

There's no manual for this. If you can't figure out how it works on your own, then you don't need the script.  

https://imgur.com/a/EwUM3kj

this is great! Thank you.

[Bram24732]

so you were going to prove that I was wrong, someday?

The arrogance is astounding.
You probably have to chage 20 or so lines of code to accomodate the script to your theory and run it by yourself, but you wont.
If this does not change your mind, nothing will and I wish you all the best.

20 lines, lol, I just want to make it clear that you shouldn't criticize without knowing. I don't criticize anyone's ideas here, so why would you come and criticize mine? If it's 20 lines, why didn't you do it? That was your main purpose, wasn't it?

I did not do it because it will never be good enough to convince you. I realize that now.
If it shows no improvement over random, you'll say it's because its numbers and not private keys..
if I change it to be private keys and your method, you'll find another way to dismiss it, and so on.
To be honest I'm quite sure you didn't bother reading it or running it. So well, you win this argument Enjoy !

You have just exposed yourself. First, it makes no sense with any of the methods discussed here. Second, where are the hashes in your test? You skipped the fundamental part of the theories here: uniform distribution of the hashes. Without hashes, there is no uniform distribution, so your script is meaningless. Lol.

I will have to think about all of what has been said and look at Bram's script and how it was used, before I can give a quality answer on it all. However, my initial thoughts with prefix padding then searching (random then sequential) versus random then sequential are a wash. Can one find lightning in a bottle by using prefixes (in whatever way, skipping keys, padding, etc.), YES.
Could Bram find the key in the first random block he/his program chooses to search, YES! But for both, the averages, tell us a different story...50% on average. So yes, both could find the key within the first minute of searching, and sometimes it may be the last possible range to search...but the averages, smooth out over x amount of tests.
Now, I say this, about the averages, but I also believe it to be true about h160 matching characters (bits) as I have seen in running numerous tests. People should not talk about averages in one way, but neglect to mention them/think about them in another way. Sometimes, I forget about one side or the other as well, so yes, I am at fault too.

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. Instead of just taking a range and dividing it by x, and then searching one of those ranges, I like the way I am doing it now, based off of h160 matches and averages. Will it solver faster? Only if I one can narrow down the paddings...narrow, may not be the right word...more like, create the largest "gap" in between found found h160 matches, without going over...maybe I should call it the H160 Matching Showcase Showdown, method...LOL. So in summary, I think ktimeG, Bram, Bibli, and McDouglas are all correct, just in different things lol.

Back to dirt and mulch...

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

From a mathematical perspective, Bram's comparison script doesn't make sense for any of the prefix ideas. The hashes are replaced by Math.floor and Math.random() to emulate. he use o a pseudo-random number generator that is not cryptographically secure. The process is 100% invalid.

Ktimesg knows this but  ... showing a double standard in their words. In my opinion, this only demonstrates that their arguments are biased,  and ironically, they dare to talk about bias. Lol.

if you want a perfectly uniform distribution just replace it by a shuffled array of all numbers from 0-N.
Results will be the same.

[uyrova818]

Are there ways to know if we are approaching the correct hex range? Theoretically.

[benjaniah]

The pubkey is there so the private key can be found in a few seconds.

How?

000000000000000000000000000000000000000000000017724AFA4320DAF4A7

He assumed the address was within 69.

Good morning, but how did you get the private key for address 19vkiEajfhnHnZjGpogP6Rv8sUQFvF7PiS, having only the public key?

Correct, I made the assumption that the private key for that wallet was in range 69. Since that address has 1 outgoing transaction, it's public key is shown. I ran RCKangaroo with the public key and got the hex private key under 5 seconds, with an RTX4070.

Code:

$ time ./rckangaroo -dp 14 -range 68 -start 100000000000000000 -pubkey 03f5c18f93f837065c3673b64f0426d08283d5097c54c465af92a399a017ddebc7

********************************************************************************
*                    RCKangaroo v3.0  (c) 2024 RetiredCoder                    *
********************************************************************************

This software is free and open-source: https://github.com/RetiredC
It demonstrates fast GPU implementation of SOTA Kangaroo method for solving ECDLP
Linux version
CUDA devices: 1, CUDA driver/runtime: 12.7/12.8
GPU 0: NVIDIA GeForce RTX 4070, 11.99 GB, 46 CUs, cap 8.9, PCI 1, L2 size: 36864 KB
Total GPUs for work: 1

MAIN MODE

Solving public key
X: F5C18F93F837065C3673B64F0426D08283D5097C54C465AF92A399A017DDEBC7
Y: 0C5EBEFBB70A7D8F266754279ECF093963B644D47C49B09B9D4107A051660F27
Offset: 0000000000000000000000000000000000000000000000100000000000000000

Solving point: Range 68 bits, DP 14, start...
SOTA method, estimated ops: 2^34.202, RAM for DPs: 0.232 GB. DP and GPU overheads not included!
Estimated DPs per kangaroo: 4.267. DP overhead is big, use less DP value if possible!
GPU 0: allocated 868 MB, 282624 kangaroos. OldGpuMode: No
GPUs started...
Stopping work ...
Point solved, K: 0.757 (with DP and GPU overheads)


PRIVATE KEY: 000000000000000000000000000000000000000000000017724AFA4320DAF4A7


real    0m4.444s
user    0m2.720s
sys     0m1.805s

[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.

[Akito S. M. Hosana]

But what are you going to do with it?

I need a script that can recover the beginning of a WIF where some characters are missing — for example, WIF500, etc  

https://github.com/NoMachine1/WIFHunter

There's no manual for this. If you can't figure out how it works on your own, then you don't need the script.  

this is great! Thank you.

Yeah, I wonder how many CPU cores it would take to solve a single prefix in under a minute. 128+ cores, maybe? Calculating SHA-256 checksums for each individual WIF is pretty demanding. A GPU-based WIF hunter, perhaps?