Bitcoin puzzle transaction ~32 BTC prize to who solves it

[bibilgin]

I've done a decent amount of work in "vanity" searches, which are basically prefix searches. However, that is normally over the entire curve, not a super small subset such as 66 or 67 bits.
And yes, my script was pretty good at it. For those who didn't know, I helped LoyceV find some crazy, some difficult, prefixes, for his project: https://bitcointalk.org/index.php?topic=5532768.0

But again, that was over the entire range and it wasn't for a prize, or the fastest to a prize. And when dealing with the whole curve, you can use some tricks. When I was helping Loyce, I kept modifying my code and eventually, it became good at looking for the types of prefixes he was looking for.
But these challenges / puzzles, and their smaller range sizes, are more problematic lol. Especially since we are looking for a complete address and we can't use more tricks (symm, endos).

Yes, everyone can talk about averages and probabilities, but at the end of the day, I do not know how or what base you would use, to say if I found x amount of h160 matching characters, I can jump x amount, because the probabilities say it will not be closer than y.

And anyone who says they can truly narrow it down, without the possibility of skipping the address we are looking for...I would not trust them lol. I don't care who they are. If I told you that, do not trust me either lol. I don't even know how you can say, well there is a x amount of chance we skip the key, but it is very low.

Old sayings I like, "Math never lies, people do" and "Facts don't care about your feelings". Which thanks to Bram, everyone can study the same data. So I did the math...it will tell you the truth.

Look at these numbers:

Code:

First Run:
- Average difference: 282602011632656
- Smallest difference: 194903573833
- Largest difference: 1946984192923367

Second Run (Excluding Smallest and Largest Differences):
- Average difference: 281241799946404

For reference, 2^48 = 281474976710656

Those numbers are from a data set of (12 matching, leading characters of the h160) prefixes found, over a range size of 2^58. Anything stick out to you?

Without removing the smallest and largest differences, the average distance is greater than 2^48, when removed, just below it. But, did you see the largest and smallest differences?

- Smallest difference: 194903573833
- Largest difference: 1946984192923367

the smallest gap between 2 prefixes was less than 38 bits and the largest gap was over 51 bits.
So, someone tell me how you can say you can widdle searches down or jump x amount, and not miss the actual key that we are looking for... (for vanity address, this is fine, but we are looking for 100% address, not just x leading prefixes)
For those that claim they have a really good formula, please explain it here. I am genuinely curious.

Thanks for the nice article and information.

Actually, as everyone knows, there is no fixed jump or pattern. But there is a jump PROBABILITY range of prefixes and hash160s.

But serious differences occur with very short prefixes. As the prefix or hash160 gets shorter, the hash decreases to fewer differences.

For example;

1MVDYgVaSN6Qy3d7W5nqGAUziqwJpKyhGu
I don't know the hex code of the wallet you shared. I think it starts with D. Because when I calculate the hash160 and the PROBABILITY with what I found, it shows that it starts with D.

But if I try to guess the 2nd hex code with low probability.
I think it is between D6 and DC. True? or False?

I have a request from you.
1MVDYgVaSN6Qy3d7W5nqGAUziqwJpKyhGu
can you make a change for this?

[teguh54321]

I've done a decent amount of work in "vanity" searches, which are basically prefix searches. However, that is normally over the entire curve, not a super small subset such as 66 or 67 bits.
And yes, my script was pretty good at it. For those who didn't know, I helped LoyceV find some crazy, some difficult, prefixes, for his project: https://bitcointalk.org/index.php?topic=5532768.0

But again, that was over the entire range and it wasn't for a prize, or the fastest to a prize. And when dealing with the whole curve, you can use some tricks. When I was helping Loyce, I kept modifying my code and eventually, it became good at looking for the types of prefixes he was looking for.
But these challenges / puzzles, and their smaller range sizes, are more problematic lol. Especially since we are looking for a complete address and we can't use more tricks (symm, endos).

Yes, everyone can talk about averages and probabilities, but at the end of the day, I do not know how or what base you would use, to say if I found x amount of h160 matching characters, I can jump x amount, because the probabilities say it will not be closer than y.

And anyone who says they can truly narrow it down, without the possibility of skipping the address we are looking for...I would not trust them lol. I don't care who they are. If I told you that, do not trust me either lol. I don't even know how you can say, well there is a x amount of chance we skip the key, but it is very low.

Old sayings I like, "Math never lies, people do" and "Facts don't care about your feelings". Which thanks to Bram, everyone can study the same data. So I did the math...it will tell you the truth.

Look at these numbers:

Code:

First Run:
- Average difference: 282602011632656
- Smallest difference: 194903573833
- Largest difference: 1946984192923367

Second Run (Excluding Smallest and Largest Differences):
- Average difference: 281241799946404

For reference, 2^48 = 281474976710656

Those numbers are from a data set of (12 matching, leading characters of the h160) prefixes found, over a range size of 2^58. Anything stick out to you?

Without removing the smallest and largest differences, the average distance is greater than 2^48, when removed, just below it. But, did you see the largest and smallest differences?

- Smallest difference: 194903573833
- Largest difference: 1946984192923367

the smallest gap between 2 prefixes was less than 38 bits and the largest gap was over 51 bits.
So, someone tell me how you can say you can widdle searches down or jump x amount, and not miss the actual key that we are looking for... (for vanity address, this is fine, but we are looking for 100% address, not just x leading prefixes)
For those that claim they have a really good formula, please explain it here. I am genuinely curious.

Does this mean we can safely jump to the smallest possible difference? 🤔

[bibilgin]

Thank you for your contribution.

This is what seems really strange: the moment when some serious users post thoughtful things, immediately there appears some fresh created account user, posting exactly something against what was being discusses. Meanwhile, the people that are bothered by the thoughtful discussions, are really happy to quickly interact and engage with all of these new-born users, who are seemingly total experts now, having lots of prefixes and so on, or wanting such prefixes.

And sure way, at the same time, everyone else is an AI / robot / clone / troll / child / clueless. But no one sees the 0-day noobs with zero activity signing the Large Prefix Catalog. Of course it makes complete sense.

I don't plan on getting into a new argument with you.

But leaving people under suspicion is a serious psychological problem.
If you think that I created or know about these accounts. I promise you. If you show the slightest proof, I will not enter the forum again.

[citb0in]

Stay focused on your path and don’t let distractions or negativity shake your determination. Success is built through consistency, patience, and resilience - every step forward matters. As the saying goes: "Do not be deceived: God cannot be mocked. A man reaps what he sows."

Stay committed, and let your vision be stronger than any obstacle.

[aby3er]

It looks so close 🙃😅.........

Any hints for Puzzle 68's first 3-digit range? Hehe.

working on it,for now not sure even about first one digit lol

[WanderingPhilospher]

1MVDYgVaSN6Qy3d7W5nqGAUziqwJpKyhGu
I don't know the hex code of the wallet you shared. I think it starts with D. Because when I calculate the hash160 and the PROBABILITY with what I found, it shows that it starts with D.

But if I try to guess the 2nd hex code with low probability.
I think it is between D6 and DC. True? or False?

It starts with 0xE.

I get what some are trying to do, I really do. I see nothing wrong with doing it this way if you are outgunned and outmatched. Maybe you get lucky before 3243294932794 (lol) GPUs beat you to it.

I just don't want people to think that you can apply a set range/jump, and not miss the actual address you are looking for.

Code:

- Smallest difference: 194903573833
- Largest difference: 1946984192923367

Is a huge difference between matching prefixes. One could go with a very low jump/exclusion range, but then that doesn't really provide a big speed up IMO.

[mcdouglasx]

To verify that if we search, for example, 3 prefixes (hex), we can skip the probability for the space of 2 prefixes '256' when we find an 'abc'. Clearly, in the space of the next 256, the probabilities of finding 'abc' are minimal. That's why my method searches in the most probable zones first and then, if necessary, reduces the percentage in the database to continue exploring without retracing steps, but always focusing on the most probable place.

Is it so difficult for AI experts to do this?:

Code:

import secrets

def generate_hex():
    return ''.join(secrets.choice('0123456789abcdef') for _ in range(2))

def calculate_probabilities(attempts):
    count_ab = 0
    count_abc = 0
    
    for _ in range(attempts):
        hex_val = generate_hex()
        if "ab" in hex_val:
            count_ab += 1
        if "abc" in hex_val:
            count_abc += 1
    
    probability_ab = count_ab / attempts
    probability_abc = count_abc / attempts
    
    return probability_ab, probability_abc

attempts = 256
samples = 1000
sum_probability_ab = 0
sum_probability_abc = 0

for _ in range(samples):
    probability_ab, probability_abc = calculate_probabilities(attempts)
    sum_probability_ab += probability_ab
    sum_probability_abc += probability_abc

average_probability_ab = sum_probability_ab / samples
average_probability_abc = sum_probability_abc / samples

print(f"Average probability of finding 'ab' in {attempts} attempts (based on {samples} samples): {average_probability_ab:.6f}")
print(f"Average probability of finding 'abc' in {attempts} attempts (based on {samples} samples): {average_probability_abc:.6f}")

[WanderingPhilospher]

To verify that if we search, for example, 3 prefixes (hex), we can skip the probability for the space of 2 prefixes '256' when we find an 'abc'. Clearly, in the space of the next 256, the probabilities of finding 'abc' are minimal. That's why my method searches in the most probable zones first and then, if necessary, reduces the percentage in the database to continue exploring without retracing steps, but always focusing on the most probable place.

Is it so difficult for AI experts to do this?:

Code:

import secrets

def generate_hex():
    return ''.join(secrets.choice('0123456789abcdef') for _ in range(2))

def calculate_probabilities(attempts):
    count_ab = 0
    count_abc = 0
    
    for _ in range(attempts):
        hex_val = generate_hex()
        if "ab" in hex_val:
            count_ab += 1
        if "abc" in hex_val:
            count_abc += 1
    
    probability_ab = count_ab / attempts
    probability_abc = count_abc / attempts
    
    return probability_ab, probability_abc

attempts = 256
samples = 1000
sum_probability_ab = 0
sum_probability_abc = 0

for _ in range(samples):
    probability_ab, probability_abc = calculate_probabilities(attempts)
    sum_probability_ab += probability_ab
    sum_probability_abc += probability_abc

average_probability_ab = sum_probability_ab / samples
average_probability_abc = sum_probability_abc / samples

print(f"Average probability of finding 'ab' in {attempts} attempts (based on {samples} samples): {average_probability_ab:.6f}")
print(f"Average probability of finding 'abc' in {attempts} attempts (based on {samples} samples): {average_probability_abc:.6f}")

Instead of using "hypothetical" data, just use real data gathered from 67. It is a ton of data, over 50% of the entire range. Pick a subset and run the numbers. That is the data I used to come up with:

Code:

First Run:
- Average difference: 282602011632656.06
- Smallest difference: 194903573833
- Largest difference: 1946984192923367

Second Run (Excluding Smallest and Largest Differences):
- Average difference: 281241799946404.22

Again, can someone do this and find the key, maybe. Could they do this and skip/miss the key, 100%.

[gygy]

To verify that if we search, for example, 3 prefixes (hex), we can skip the probability for the space of 2 prefixes '256' when we find an 'abc'. Clearly, in the space of the next 256, the probabilities of finding 'abc' are minimal. That's why my method searches in the most probable zones first and then, if necessary, reduces the percentage in the database to continue exploring without retracing steps, but always focusing on the most probable place.

There are no more probable or less probable ranges. There are no ranges that you can safely skip. I can assure you it is not in the lower half of the range with a 50% chance. The thing you are trying to sell is the same with other probabilities. It is random.

Based on the fact you found some address you cannot have any conclusions about addresses near that private key.

What if you check postfixes instead of prefixes. Is that the same? If it is, that what if you check in different bases instead of 16?

This is just superstition, and sadly for a while this is what is this forum topic is about. This and bad python codes.

[mcdouglasx]

Again, can someone do this and find the key, maybe. Could they do this and skip/miss the key, 100%.

With this, I see that you don't understand my logic. There's no way to lose the target since it is self-adjusting, designed to focus on the most probable range down to the least probable. It covers the entire range. I thought you understood it the last time. Maybe you are confusing it with Bibilgin. Honestly, I don't see the logic of Bibilgin as viable in my head, but this one is, because I only do what you call a 'full random' search. Instead of dividing into subranges, I focus on avoiding less probable ranges, and then if necessary, I narrow down the path. Honestly, I don't understand why there is so much fuss about this; it's just probabilities.

[WanderingPhilospher]

Again, can someone do this and find the key, maybe. Could they do this and skip/miss the key, 100%.

With this, I see that you don't understand my logic. There's no way to lose the target since it is self-adjusting, designed to focus on the most probable range down to the least probable. It covers the entire range. I thought you understood it the last time. Maybe you are confusing it with Bibilgin. Honestly, I don't see the logic of Bibilgin as viable in my head, but this one is, because I only do what you call a 'full random' search. Instead of dividing into subranges, I focus on avoiding less probable ranges, and then if necessary, I narrow down the path. Honestly, I don't understand why there is so much fuss about this; it's just probabilities.

Then yes, I would need to see more, or in application. Maybe a further explanation of what happens before the search (if anything), and during the search.

[bibilgin]

It starts with 0xE.

I get what some are trying to do, I really do. I see nothing wrong with doing it this way if you are outgunned and outmatched. Maybe you get lucky before 3243294932794 (lol) GPUs beat you to it.

I just don't want people to think that you can apply a set range/jump, and not miss the actual address you are looking for.

Is a huge difference between matching prefixes. One could go with a very low jump/exclusion range, but then that doesn't really provide a big speed up IMO.

There is also a possibility of skipping the wallet. You are right.
(We eat the first candy we like.)

I can say that you kept the similar prefix short.

I sent a PM. Can you answer?

[DmitryMerk]

I have 15 PRIV (hex) for prefix e0b8a2baee1b
And 50 PRIV (hex) for prefix e0b8a2baee1

Maybe someone wants to change with me?)

[kTimesG]

This is just superstition, and sadly for a while this is what is this forum topic is about. This and bad python codes.

I guess you haven't seen COBRAS's.

What's wrong with having code that explodes in complexity? Most people here have zero clues about algorithms, and they complicate things terribly instead of simplifying them. Mostly because things can't really be simplified, so desperate solutions appear.

Here's a quick way to compute the prefix size, in number of bits, without having to run a loop across string searching for hex non-sense:

Code:

h160_c = int.from_bytes(h160)  #  this is a CONSTANT integer
# Magical XOR. Read it up on Wikipedia.
prefix_len = 160 - (h160_c ^ int.from_bytes(h160_d)).bit_length()

This is what people did, well, IDK, before AI made us all experts in bad coding. It's called using a brain.

[mcdouglasx]

Again, can someone do this and find the key, maybe. Could they do this and skip/miss the key, 100%.

With this, I see that you don't understand my logic. There's no way to lose the target since it is self-adjusting, designed to focus on the most probable range down to the least probable. It covers the entire range. I thought you understood it the last time. Maybe you are confusing it with Bibilgin. Honestly, I don't see the logic of Bibilgin as viable in my head, but this one is, because I only do what you call a 'full random' search. Instead of dividing into subranges, I focus on avoiding less probable ranges, and then if necessary, I narrow down the path. Honestly, I don't understand why there is so much fuss about this; it's just probabilities.

Then yes, I would need to see more, or in application. Maybe a further explanation of what happens before the search (if anything), and during the search.

I understand that they need to know more about what I mean, but I haven't even published the keyhunt mod yet, and I almost receive mocking attacks every 10 minutes. It seems easier for people to attack these days, even based on assumptions, without even knowing the idea they're attacking. It's funny to me.

But come on, you know what I mean. I don't see a problem with probabilistic software for a huge space, especially if there's no risk of losing the key. In the worst-case scenario, it just adjusts a smaller percentage until it reaches 0% (which means scanning everything). I don't think this is so hard to understand.

[DmitryMerk]

https://www.talkimg.com/images/2025/03/12/0vJZT.png

I try to visualize my founded keys with prefix e0b8a2baee1

[WanderingPhilospher]

Again, can someone do this and find the key, maybe. Could they do this and skip/miss the key, 100%.

With this, I see that you don't understand my logic. There's no way to lose the target since it is self-adjusting, designed to focus on the most probable range down to the least probable. It covers the entire range. I thought you understood it the last time. Maybe you are confusing it with Bibilgin. Honestly, I don't see the logic of Bibilgin as viable in my head, but this one is, because I only do what you call a 'full random' search. Instead of dividing into subranges, I focus on avoiding less probable ranges, and then if necessary, I narrow down the path. Honestly, I don't understand why there is so much fuss about this; it's just probabilities.

Then yes, I would need to see more, or in application. Maybe a further explanation of what happens before the search (if anything), and during the search.

I understand that they need to know more about what I mean, but I haven't even published the keyhunt mod yet, and I almost receive mocking attacks every 10 minutes. It seems easier for people to attack these days, even based on assumptions, without even knowing the idea they're attacking. It's funny to me.

But come on, you know what I mean. I don't see a problem with probabilistic software for a huge space, especially if there's no risk of losing the key. In the worst-case scenario, it just adjusts a smaller percentage until it reaches 0% (which means scanning everything). I don't think this is so hard to understand.

Are you talking about the script you made where it pads each side of a found key so that area is skipped if landed on again? Or something else?

If we are talking same script, yes, I see problems with it. If you are talking something else, then I can't say.  Sorry if we are talking about 2 different things lol.

[mcdouglasx]

Again, can someone do this and find the key, maybe. Could they do this and skip/miss the key, 100%.

With this, I see that you don't understand my logic. There's no way to lose the target since it is self-adjusting, designed to focus on the most probable range down to the least probable. It covers the entire range. I thought you understood it the last time. Maybe you are confusing it with Bibilgin. Honestly, I don't see the logic of Bibilgin as viable in my head, but this one is, because I only do what you call a 'full random' search. Instead of dividing into subranges, I focus on avoiding less probable ranges, and then if necessary, I narrow down the path. Honestly, I don't understand why there is so much fuss about this; it's just probabilities.

Then yes, I would need to see more, or in application. Maybe a further explanation of what happens before the search (if anything), and during the search.

I understand that they need to know more about what I mean, but I haven't even published the keyhunt mod yet, and I almost receive mocking attacks every 10 minutes. It seems easier for people to attack these days, even based on assumptions, without even knowing the idea they're attacking. It's funny to me.

But come on, you know what I mean. I don't see a problem with probabilistic software for a huge space, especially if there's no risk of losing the key. In the worst-case scenario, it just adjusts a smaller percentage until it reaches 0% (which means scanning everything). I don't think this is so hard to understand.

Are you talking about the script you made where it pads each side of a found key so that area is skipped if landed on again? Or something else?

If we are talking same script, yes, I see problems with it. If you are talking something else, then I can't say.  Sorry if we are talking about 2 different things lol.

The idea of prefixes is complete and carries no risk of losing the key, with better statistics among other things. That's why I say it's at least absurd to receive criticism based on assumptions. From the beginning, I talked about creating a mod for Keyhunt. I've uploaded photos here, and in each of my posts, I include a disclaimer that the script is merely a representation of an idea. Then I see people complaining, and I think, didn't they read that this was just a concept or a kind of draft that serves as the basis for the idea?

Anyway, I explained my idea and I know it works; I have been testing it. But I anticipate what will happen: they will focus on the possible code flaws and criticize it because it's fashionable here to feel superior. They will put the idea in the background. For example, if I leave the database in plain text so they can understand it, they'll say it's better to optimize it with bytes, etc.

In short, another day at the puzzle bots office. Lol. Everyone counters what they assume with basic probability. I demonstrate with a basic script, and that bothers them. They only see what they want to see, blind in their own ignorance.

[teguh54321]

1MVDYgVaSN6Qy3d7W5nqGAUziqwJpKyhGu
I don't know the hex code of the wallet you shared. I think it starts with D. Because when I calculate the hash160 and the PROBABILITY with what I found, it shows that it starts with D.

But if I try to guess the 2nd hex code with low probability.
I think it is between D6 and DC. True? or False?

It starts with 0xE.

I get what some are trying to do, I really do. I see nothing wrong with doing it this way if you are outgunned and outmatched. Maybe you get lucky before 3243294932794 (lol) GPUs beat you to it.

I just don't want people to think that you can apply a set range/jump, and not miss the actual address you are looking for.

Code:

- Smallest difference: 194903573833
- Largest difference: 1946984192923367

Is a huge difference between matching prefixes. One could go with a very low jump/exclusion range, but then that doesn't really provide a big speed up IMO.

Maybe add a matching prefix code in the brute-force cracking process—if it matches, then jump, skipping 120,000,000,000. If it jumps 20 times, that means skipping 20 × 120,000,000,000.  🤔

But the matching code process might also slow down the entire brute-force process. Hmmm 🙃

[WanderingPhilospher]

The idea of prefixes is complete and carries no risk of losing the key, with better statistics among other things.

So point me to this new idea of yours, maybe I missed it.

Again, if it is the database padding you wrote, there are flaws in it and finding the key is not guaranteed, without possibly going back and tweaking the walls around the keys, monitoring how many keys are left to check to make sure it's not continuing to randomly jump around, finding no matches, etc.

I like the idea, but it is still flawed, even with the tweaks I made. I have one db that has over 8 million keys found (now padded ranges) in it lol, 8 matches up to 14/15. Yes, over 8 million, supplemented by GPU search obviously. But in doing so, I knew there are still flaws as we can guesstimate a padding, but it could be too large and skip the key on the first iteration, or too small and wasting time vs plain brute force.

I'm not critiquing, I am wondering if you are talking of some other project of yours. If so, point me in the right direction.