Bitcoin puzzle transaction ~32 BTC prize to who solves it

[WanderingPhilospher]

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.

[kTimesG]

Yes, you can replace any key by other key.

A logical speedup is to ignore the rest of the elements in the range/set, and choose a new range/set, to maximize chances to find another new element.

Then the new set has exactly the same odds to find a match as the set you were about to run when finishing the range.
It feels counter intuitive, I know. If you want to be convinced just run the odds of both cases by taking a range of size 1000 with 5% probability.

Then how do you explain this: if I have some 32 bits mask, and jump keys based on how many bits the mask matched, then I hash less keys overall, but the total matches are, on average, much better finds than if I traverse linearly?.

Or are you saying that this does not happen?

Oh this can clearly happen on a small enough subset because of the huge deviations that may happen.It would not work as well on a bigger scale because everything would even out.

Yeah, seems I hurried a bit. I only averaged the best matches; if all the possible prefix lengths are included, then on average there is only a 1.0000... bits prefix match, long-term.

This is identical to simply not even doing a prefix match at all. Because, on average, a H160 hash has a length of 159 bits. Zero improvement trying to break the hash distribution.

It also doesn't matter whether the hash inputs are random data or produced by EC scalar-mul.

It is just placebo to think that, by "skipping" a number of hashes (no matter in what way you do that) you maximize chances to obtain, in a faster way, some prefix. The same exact thing would happen if the keys are hashed in continuation, or the hashing is done on random inputs. Or if you simply wait it out, drink a coffee, and hash a bit more from where you left off. Or simply ignore the results of a couple of hashes and then go as usual.

Set/range A: keys 1 to N
Set/range B: keys N + 1 to 2N (or some other M to M + size)

After A is scanned (fully or not), we can simply swap keys from B into A (or not), there is no correlation between the way we split the sets, and what the hashing produces. Unless there is a link between the private key and the H160, this is where conspiracy theories begin.

[aby3er]

Hey everyone /
if someone needs for 69:
19vkiEajfh i9pMP9v4vtttK8BtkwqLjafX
(WIF): p2pkh: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qhGYQWpyawGq7TeLoEkQ
(HEX): 17353DBA52F00471D3

 

[kTimesG]

Hey everyone /
if someone needs for 69:
19vkiEajfh i9pMP9v4vtttK8BtkwqLjafX
(WIF): p2pkh: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qhGYQWpyawGq7TeLoEkQ
(HEX): 17353DBA52F00471D3

 

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.

[nomachine]

you can speed up this Python code 100 times in Cyclone.

How do you think prefixes can be generated in Cyclone?

There is already a search in the script using AVX2 instructions to compare two 128-bit values.
However, the search focus on the last 4 bytes of the hashes rather than just the beginning.

Code:

// 8 keys are ready - time to use avx2
                if (localBatchCount == HASH_BATCH_SIZE) {
                    computeHash160BatchBinSingle(localBatchCount, localPubKeys, localHashResults);
                    // Results check
                    for (int j = 0; j < HASH_BATCH_SIZE; j++) {
                        __m128i cand16 = _mm_loadu_si128(reinterpret_cast<const __m128i*>(localHashResults[j]));
                        __m128i cmp = _mm_cmpeq_epi8(cand16, target16);
                        if (_mm_movemask_epi8(cmp) == 0xFFFF) {
                            // Checking last 4 bytes (20 - 16)

A Bitcoin address is derived from a RIPEMD-160 hash (20 bytes).
To match 1MVDYgVaSN, you need to match the first 10 bytes.

Code:

// Modify the comparison logic to check only the first 10 bytes
if ((_mm_movemask_epi8(cmp) & 0x03FF) == 0x03FF) {
    // Check the first 10 bytes of the hash160 result
    if (!matchFound && std::memcmp(localHashResults[j], targetHash160.data(), 10) == 0) {
        #pragma omp critical
        {
            if (!matchFound) {
                matchFound = true;
                auto tEndTime = std::chrono::high_resolution_clock::now();
                globalElapsedTime = std::chrono::duration<double>(tEndTime - tStart).count();
                mkeysPerSec = (double)(globalComparedCount + localComparedCount) / globalElapsedTime / 1e6;

                // Recovering private key
                Int matchingPrivateKey;
                matchingPrivateKey.Set(&currentBatchKey);
                int idx = pointIndices[j];
                if (idx < 256) {
                    Int offset; offset.SetInt32(idx);
                    matchingPrivateKey.Add(&offset);
                } else {
                    Int offset; offset.SetInt32(idx - 256);
                    matchingPrivateKey.Sub(&offset);
                }
                foundPrivateKeyHex = padHexTo64(intToHex(matchingPrivateKey));

                // Print the partial match and private key
                std::string first10(reinterpret_cast<char*>(localHashResults[j]), 10);
                std::cout << "Partial Match Found! First 10 bytes: " << first10 << "\n";
                std::cout << "Private Key: " << foundPrivateKeyHex << "\n";
            }
        }
        #pragma omp cancel parallel
    }
    localComparedCount++;
} else {
    localComparedCount++;
}

Something like this, but I don't believe in prefixes anymore either. I did that in the beginning, and I don't even know what I haven't tried. The pattern doesn't exist. This is just useless fun....

[teguh54321]

Hey everyone /
if someone needs for 69:
19vkiEajfh i9pMP9v4vtttK8BtkwqLjafX
(WIF): p2pkh: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qhGYQWpyawGq7TeLoEkQ
(HEX): 17353DBA52F00471D3

 

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

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

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