Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Jorge54PT]

As he said, let's hope it's the right range.

3 machines - sequential mode, whether with prefix, address or ripmd160.

4-5
5-6
6-7

solve the problem more faster but the private key will always be 0x17 characters.

It will not resolve if the key is not in the range 4000000000000000000:7ffffffffffffffff

[kTimesG]

I do not have these found wallets / prefixes because I think they will show me a pattern. I have them as PoW that I completed a specific range, in case I wanted to swap ranges with someone down the road.

I am telling you the point you do not understand. I guess the English translation is not correct in some places.

If you wish, I can send you a few more HEX codes with the prefix 1BY8GQbnueY. Maybe it will help with your pattern.
...
You do not want to understand or agree.

This is what happens when someone reads what they want to understand, not what the words spell out.

bibilgin, it is already an act of patience on all of us to understand your terminology:

"HEX code" = private key? Do you honestly not care that "HEX code" and "private key" are two totally semantically different concepts?

"wallet" = base58 encoded address? Do you honestly not care the difference between a wallet and an address?

No one cares about your prefixes catalog, they are useless. Everyone is telling you they do not matter and that they have exactly zero statistical significance or relevance. AND that there is no pattern. Learn to read phrases (in full maybe, to reach the logical sentence)?

I also have a strange suspicion that your prefixes or whatever are not even in correlation with the actual starting bits of the RIPEMD-160 hash. As in, your starting bits are not even correct, depending on the prefix. So you might be hunting down stuff that has some prefix length, but in reality the hash bits start to be different earlier than what you think. But then again, you're the real expert here, and all of us are idiots, so you should know better. That is, after you stop confusing hex codes with private keys, and wallets with addresses. Or actually making some sense in general.

You want to know the kicker? ALL of your prefixes are wrong, because they definitely are not the same prefix as the target address. The only correct prefix is the one that has the same length as the "wallet", and, again, as everyone tries to tell you, requires searching every single "HEX code", no skips, no jumps, no assumptions, because, fuck, MATH and PROBABILITIES.

[bibilgin]

This is what happens when someone reads what they want to understand, not what the words spell out.

bibilgin, it is already an act of patience on all of us to understand your terminology:

"HEX code" = private key? Do you honestly not care that "HEX code" and "private key" are two totally semantically different concepts?

"wallet" = base58 encoded address? Do you honestly not care the difference between a wallet and an address?

No one cares about your prefixes catalog, they are useless. Everyone is telling you they do not matter and that they have exactly zero statistical significance or relevance. AND that there is no pattern. Learn to read phrases (in full maybe, to reach the logical sentence)?

I also have a strange suspicion that your prefixes or whatever are not even in correlation with the actual starting bits of the RIPEMD-160 hash. As in, your starting bits are not even correct, depending on the prefix. So you might be hunting down stuff that has some prefix length, but in reality the hash bits start to be different earlier than what you think. But then again, you're the real expert here, and all of us are idiots, so you should know better. That is, after you stop confusing hex codes with private keys, and wallets with addresses. Or actually making some sense in general.

You want to know the kicker? ALL of your prefixes are wrong, because they definitely are not the same prefix as the target address. The only correct prefix is the one that has the same length as the "wallet", and, again, as everyone tries to tell you, requires searching every single "HEX code", no skips, no jumps, no assumptions, because, fuck, MATH and PROBABILITIES.

I understand you and the others very well.

But, as the creator said, this is a test of social cracking power.
Actually, it is a competition. Everyone can have a different idea, a different work.

The strategy I have done is to find the prefixes that are in a certain range.
For example, if I found a similar one that starts with 6F123F4..., I calculate the other similar prefix. For example, I move on to the other prefix that starts with 6F543F1.... I also record all my scans.

Yes, is there a possibility of being between these? I definitely agree with you. But after creating certain points, I find the range of the other similar prefix on PROBABILITY. (But not in the same length range.)

I wish everyone success in their work. If there are no different ideas, different works, this competition cannot progress. Because it will be a competition that only those who are equipped will win.

[WanderingPhilospher]

In all seriousness, how many (sticking to averages of math / the curve) BY8GQbnueY prefixes are in a 66 bit space? I come up with 171. Is that correct or close to what others think / know?

And for the prefix, BY8GQbnue, a little less than 10k inside a 66 bit space?

If there are no different ideas, different works, this competition cannot progress.

I think the issue with your statement, is, others have tried this method, and to my knowledge, no one has found the key, using the same or similar methods. But maybe you will be the first!

[invisibleecho]

In all seriousness, how many (sticking to averages of math / the curve) BY8GQbnueY prefixes are in a 66 bit space? I come up with 171. Is that correct or close to what others think / know?

And for the prefix, BY8GQbnue, a little less than 10k inside a 66 bit space?

If there are no different ideas, different works, this competition cannot progress.

I think the issue with your statement, is, others have tried this method, and to my knowledge, no one has found the key, using the same or similar methods. But maybe you will be the first!

Not sure why it's useful to know how many prefixes of exactly 10 matching chars exist within the 66 key space, since public keys are distributed randomly within the curve and since the ripemd hashing loses information anyways I would not consider this helpful in any way. However, log2(58) = 5.858 * 10 = 58.57 bits, so for 66 bit range 66 - 58.57 = 7.43 so 2^7.43 equals approx. 172 possible prefixes.

However, how is that useful?

[WanderingPhilospher]

In all seriousness, how many (sticking to averages of math / the curve) BY8GQbnueY prefixes are in a 66 bit space? I come up with 171. Is that correct or close to what others think / know?

And for the prefix, BY8GQbnue, a little less than 10k inside a 66 bit space?

If there are no different ideas, different works, this competition cannot progress.

I think the issue with your statement, is, others have tried this method, and to my knowledge, no one has found the key, using the same or similar methods. But maybe you will be the first!

Not sure why it's useful to know how many prefixes of exactly 10 matching chars exist within the 66 key space, since public keys are distributed randomly within the curve and since the ripemd hashing loses information anyways I would not consider this helpful in any way. However, log2(58) = 5.858 * 10 = 58.57 bits, so for 66 bit range 66 - 58.57 = 7.43 so 2^7.43 equals approx. 172 possible prefixes.

However, how is that useful?

I didn't say it was or was not useful, cho. Just wanted someone to check my sanity.

I imagine, it some how ties into what bibs is doing. If there are only 172 of those prefixes, then they have to break the 66 bit range into 172 chunks, and that's even if they are somewhat evenly distributed. Maybe one could find the first occurrence and the last occurrence, and make the overall range smaller, but it's still a lot, and skipping one could happen very easily.

[saeedxxx]

In all seriousness, how many (sticking to averages of math / the curve) BY8GQbnueY prefixes are in a 66 bit space? I come up with 171. Is that correct or close to what others think / know?

And for the prefix, BY8GQbnue, a little less than 10k inside a 66 bit space?

If there are no different ideas, different works, this competition cannot progress.

I think the issue with your statement, is, others have tried this method, and to my knowledge, no one has found the key, using the same or similar methods. But maybe you will be the first!

I think there are more! for BY8GQbnueY, I came up with 425 and for BY8GQbnue, 24688. These results are based on the difficulty that Vanitysearch shows...

[kTimesG]

In all seriousness, how many (sticking to averages of math / the curve) BY8GQbnueY prefixes are in a 66 bit space? I come up with 171. Is that correct or close to what others think / know?

And for the prefix, BY8GQbnue, a little less than 10k inside a 66 bit space?

I think there are more! for BY8GQbnueY, I came up with 425 and for BY8GQbnue, 24688. These results are based on the difficulty that Vanitysearch shows...

^ These are the correct values. Feel free to correct me.

Note: this does not help with anything, the real result is the one obtained after actually traversing the entire desired subset of 2**66 hashes (for example, the sequential target range for Puzzle 67), and counting the observed prefixes. So the deviation between ideal and real result can be magnitudes larger or lower.

Also, it should be a very quick realization that some prefixes are much more important then others, due to the base change (binary <-> base58).

Code:

min = base58.b58decode('1BY8GQbnueY11111111111111111111111').hex()
max = base58.b58decode('1BY8GQbnueYzzzzzzzzzzzzzzzzzzzzzzz').hex()

# Get total possibilities, and remove checksum bytes
n = (int(max, 16) - int(min, 16) + 1) >> 32

# Get AVERAGE count over ANY 66 bits set
n = n / (2**(160 - 66))

print(n)

Code:

425.6615266237625

Code:

min = base58.b58decode('1BY8GQbnue111111111111111111111111').hex()
max = base58.b58decode('1BY8GQbnuezzzzzzzzzzzzzzzzzzzzzzzz').hex()

# Get total possibilities, and remove checksum bytes
n = (int(max, 16) - int(min, 16) + 1) >> 32

# Get AVERAGE count over ANY 66 bits set
n = n / (2**(160 - 66))

print(n)

Code:

24688.368544178225

[WanderingPhilospher]

In all seriousness, how many (sticking to averages of math / the curve) BY8GQbnueY prefixes are in a 66 bit space? I come up with 171. Is that correct or close to what others think / know?

And for the prefix, BY8GQbnue, a little less than 10k inside a 66 bit space?

I think there are more! for BY8GQbnueY, I came up with 425 and for BY8GQbnue, 24688. These results are based on the difficulty that Vanitysearch shows...

^ These are the correct values. Feel free to correct me.

Note: this does not help with anything, the real result is the one obtained after actually traversing the entire desired subset of 2**66 hashes (for example, the sequential target range for Puzzle 67), and counting the observed prefixes. So the deviation between ideal and real result can be magnitudes larger or lower.

Also, it should be a very quick realization that some prefixes are much more important then others, due to the base change (binary <-> base58).

Code:

min = base58.b58decode('1BY8GQbnueY11111111111111111111111').hex()
max = base58.b58decode('1BY8GQbnueYzzzzzzzzzzzzzzzzzzzzzzz').hex()

# Get total possibilities, and remove checksum bytes
n = (int(max, 16) - int(min, 16) + 1) >> 32

# Get AVERAGE count over ANY 66 bits set
n = n / (2**(160 - 66))

print(n)

Code:

425.6615266237625

Code:

min = base58.b58decode('1BY8GQbnue111111111111111111111111').hex()
max = base58.b58decode('1BY8GQbnuezzzzzzzzzzzzzzzzzzzzzzzz').hex()

# Get total possibilities, and remove checksum bytes
n = (int(max, 16) - int(min, 16) + 1) >> 32

# Get AVERAGE count over ANY 66 bits set
n = n / (2**(160 - 66))

print(n)

Code:

24688.368544178225

Agree, it's all hypotheticals AND the real numbers would change based on the specific 66 bit range ran.

I guess my "issue" with the above math, taking the 10 character prefix, as an example:

If you ran this:

Code:

min = base58.b58decode('1BY8GQbnueY11111111111111111111111').hex()
max = base58.b58decode('1BY8GQbnueYzzzzzzzzzzzzzzzzzzzzzzz').hex()

for every possible 10 character prefix, from:

Code:

min = base58.b58decode('1111111111111111111111111111111111').hex()
max = base58.b58decode('11111111111zzzzzzzzzzzzzzzzzzzzzzz').hex()

through:

Code:

min = base58.b58decode('1zzzzzzzzzz11111111111111111111111').hex()
max = base58.b58decode('1zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz').hex()

and each one spits out "425", then that is more than 2.5 times larger than the 66 bit range. 58^10 x 425   /   2^66  =  2.48

I know this is all hypotheticals, but I struggle with the above formula because of how much larger it actually is versus a 66 bit range.

Maybe I will run some smaller, but quicker tests, just to see how close each formula is.

[saeedxxx]

It’s because of the behavior of base58!
https://bitcoin.stackexchange.com/questions/18371/why-are-bitcoin-addresses-starting-with-1s-or-1s-so-rare

[bibilgin]

I have a message for everyone here.

1- Stop asking questions privately by opening new users.
(If you are a bit of a man, write from your own username and ask.)

2- I do not want to share any information with anyone.

3- I do not care what anyone says. (Let every brave man eat his yogurt, it is not a man's job to look at what is on someone else's plate.)

It’s because of the behavior of base58!
https://bitcoin.stackexchange.com/questions/18371/why-are-bitcoin-addresses-starting-with-1s-or-1s-so-rare

Finally someone started seeing things.
Congrats man.

Example: 1BY8GQbnuc prefix, definitely not around 10k.
In the range of 4000... - 7FFF..

The majority of letters after the 1BY8GQbnu prefix that most searchers encounter.

1BY8GQbnu2 - 1BY8GQbnuB - 1BY8GQbnuC - 1BY8GQbnuf - 1BY8GQbnuH - 1BY8GQbnui - 1BY8GQbnuk - 1BY8GQbnuL - 1BY8GQbnuQ - 1BY8GQbnuU...

Does anyone know why this is happening?

[kTimesG]

I guess my "issue" with the above math, taking the 10 character prefix, as an example:

If you ran this:

Code:

min = base58.b58decode('1BY8GQbnueY11111111111111111111111').hex()
max = base58.b58decode('1BY8GQbnueYzzzzzzzzzzzzzzzzzzzzzzz').hex()

for every possible 10 character prefix, from:

Code:

min = base58.b58decode('1111111111111111111111111111111111').hex()
max = base58.b58decode('11111111111zzzzzzzzzzzzzzzzzzzzzzz').hex()

through:

Code:

min = base58.b58decode('1zzzzzzzzzz11111111111111111111111').hex()
max = base58.b58decode('1zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz').hex()

and each one spits out "425", then that is more than 2.5 times larger than the 66 bit range. 58^10 x 425   /   2^66  =  2.48

I know this is all hypotheticals, but I struggle with the above formula because of how much larger it actually is versus a 66 bit range.

Maybe I will run some smaller, but quicker tests, just to see how close each formula is.

You are totally correct that 58**10 * 425 > 2**66, but I fail to understand why is this important?

Yes, every base58 char can have values (0, 57), but if you do log(2**160, 58) you will see that it is not an exact integer (and we can't have addresses with a fractional length, right?), so your formula needs to be adjusted so that those "10 characters prefix" means "10 out of an average 27.3132 characters", and/or the base is also lower than 58, since any given character of an address encodes on average less than 58 values (so that x**addr_len == 2**160).

Anyway, this only shows further how useless it is to use the prefix as any sort of reliable attack, instead of the RIPEMD hash directly.

Finally someone started seeing things.
Congrats man.

Example: 1BY8GQbnuc prefix, definitely not around 10k.
In the range of 4000... - 7FFF..

The majority of letters after the 1BY8GQbnu prefix that most searchers encounter.

1BY8GQbnu2 - 1BY8GQbnuB - 1BY8GQbnuC - 1BY8GQbnuf - 1BY8GQbnuH - 1BY8GQbnui - 1BY8GQbnuk - 1BY8GQbnuL - 1BY8GQbnuQ - 1BY8GQbnuU...

Does anyone know why this is happening?

Oh no. Enlighten us? Can you stop using the forum as your personal diary of prefixes for the next 10 years,  please? You will only end up brute-forcing the non-brute forced ranges.

[bibilgin]

Oh no. Enlighten us? Can you stop using the forum as your personal diary of prefixes for the next 10 years,  please? You will only end up brute-forcing the non-brute forced ranges.

No, I haven't enlightened you yet. If you can't answer the questions, I can continue asking questions. For 10 years.

[mcdouglasx]

and each one spits out "425", then that is more than 2.5 times larger than the 66 bit range. 58^10 x 425   /   2^66  =  2.48

I know this is all hypotheticals, but I struggle with the above formula because of how much larger it actually is versus a 66 bit range.

Maybe I will run some smaller, but quicker tests, just to see how close each formula is.

you can't really use base58 for these calculations, bitcoin uses Base58Check which must follow certain rules and avoids certain characters that can cause confusion, thus decreasing the probabilities, it must be calculated based on ripemd160. in bitcoin there are 2^256 possible RIPEMD-160 hash values, it is implicit that most of them have duplicates, let's suppose we want to find the hashes that repeat the first 15 hexadecimal digits, because 15 hex represent 60 bits, let's say that the probability of it being repeated is 1/2**60.

[kTimesG]

Oh no. Enlighten us? Can you stop using the forum as your personal diary of prefixes for the next 10 years,  please? You will only end up brute-forcing the non-brute forced ranges.

No, I haven't enlightened you yet. If you can't answer the questions, I can continue asking questions. For 10 years.

It seemed you were the one just waiting to give us an excellent explanation to this unknown mystery. You are really confusing everyone here for idiots, as if you're the only one holding true answers while we're scratching our heads in hopes our IQ goes up. We already know why some prefixes are found more often, it is obvious and normal. This is not your personal class room to teach us your flawed perceptions and wrong theories... why not use your genius in solitude, instead of bugging us? Oh and since you're just on the edge of solving Puzzle 67, I hope you also have a really good strategy to not expose the public key to anyone anywhere, before your TX gets mined.

[bibilgin]

Oh no. Enlighten us? Can you stop using the forum as your personal diary of prefixes for the next 10 years,  please? You will only end up brute-forcing the non-brute forced ranges.

No, I haven't enlightened you yet. If you can't answer the questions, I can continue asking questions. For 10 years.

It seemed you were the one just waiting to give us an excellent explanation to this unknown mystery. You are really confusing everyone here for idiots, as if you're the only one holding true answers while we're scratching our heads in hopes our IQ goes up. We already know why some prefixes are found more often, it is obvious and normal. This is not your personal class room to teach us your flawed perceptions and wrong theories... why not use your genius in solitude, instead of bugging us? Oh and since you're just on the edge of solving Puzzle 67, I hope you also have a really good strategy to not expose the public key to anyone anywhere, before your TX gets mined.

I don't have any answers.
I'm just looking for answers to my questions. But everyone writes what they know, or rather, only what they read. A few people are just after something different, but thanks to personalities like you, they don't speak up.

It doesn't matter whether TX is exposed during the transfer. I'll use MARA, and I'll also write SHA256 or SHA512 partial information here. Even if there's a problem during the transfer and a thief steals it, I won't be too upset. It's not just about money. Many virtues are enough.

[Kelvin555]

I am sure that the creator of this challenge will be laughing out loud when going through this thread daily.  

Some have gone mad trying to find a pattern just so to get the reward, some have turned to sorcery, drawing magic circles just so to get the reward, some have turned authoritarians fighting against degeneracy in the thread.

At the end none of them will get the reward or the reward will be stolen from them.

I read this thread daily just for the lolz

[Geshma]

This script is a simple way to try to check for statistical patterns in the results of a hash160. Even if exact patterns are not found, relatively close matches with approximate intervals are visualized, and I suppose this is what is being explored here. Still, cryptographic hashes are designed to minimize the probability of discernible patterns. However, questioning mathematics has never been wrong; it has always been the driving force of development. As I always say, statistics are counterintuitive, so we can only observe and see where the investigation leads.

Code:

import hashlib
import random

def random_256():
    return ''.join([random.choice('0123456789ABCDEF') for _ in range(64)])

def hripemd160(hex_str):
    ripemd160 = hashlib.new('ripemd160')
    ripemd160.update(bytes.fromhex(hex_str))
    return ripemd160.hexdigest()

thashes = 0
count = 0

while True:
    thashes += 1
    hex_256 = random_256()
    hash160 = hripemd160(hex_256)
    
    if hash160.startswith('1111'):
        count += 1
        print(f"Simulated Hash256: {hex_256} -> Hash160: {hash160}")
        print(f"Pattern found after {thashes} hashes.")
        thashes = 0

    if count >= 100:
        break

can we add hash table to the code and use DP to store pk for lookup?

[hoanghuy2912]

Seriously, does anyone have the public key for this puzzle please let me know, I think I know the specific range close to hex of the private key

[WanderingPhilospher]

It’s because of the behavior of base58!
https://bitcoin.stackexchange.com/questions/18371/why-are-bitcoin-addresses-starting-with-1s-or-1s-so-rare

Agreed, that's why the:

Code:

min = base58.b58decode('1BY8GQbnueY11111111111111111111111').hex()
max = base58.b58decode('1BY8GQbnueYzzzzzzzzzzzzzzzzzzzzzzz').hex()

Throws me off, because it doesn't take into consideration, everything. I know years ago this was a topic of discussion, not to find patterns but to base payment for vanity addresses.

This was a good start (JLPs):

Code:

double VanitySearch::getDiffuclty() {

  double min = pow(2,160);

  if (onlyFull)
    return min;

  for (int i = 0; i < (int)usedPrefix.size(); i++) {
    int p = usedPrefix[i];
    if (prefixes[p].items) {
      for (int j = 0; j < (int)prefixes[p].items->size(); j++) {
        if (!*((*prefixes[p].items)[j].found)) {
          if ((*prefixes[p].items)[j].difficulty < min)
            min = (*prefixes[p].items)[j].difficulty;
        }
      }
    }
  }

  return min;

}

But I think the individual even broke it down even further (don't remember how or what was used). Thanks to you and ktimesg for the input!

No, it is not right. It is way under 19 decimals lol.

Look bib, I have more prefixes than you do, so don't try to educate me on "...in fact there are many wallets with similar prefixes", this has been known for years lol.

You posted a hex and wallet, and I told you which one I think may be the closest, based on what I have. I could hash away to try and find maybe the one you think is the closest to it, but I won't.

You could tell me the hex of the one you think is closest, and I can tell you if that is closer than the one I posted.

Okay, you didn't even write how many digits of decimal difference there is?

Wallet: 1BY8GQbnuewAjHWYH7QSc8e3uBK6d7reZT
Hex: 6F83E14DED2761731

Let's see if you can write it. Hex code.

Or will you say mine is farther, closer?

I hate to double post, buuuuuut I didn't want this one to get lost in the shuffle of my other post, there is one closer to 6F82ECCA251ACF143 than 6F83E14DED2761731, and I have it lol.

1BY8GQbnuec3Vp8YimiL8Bf17UfP1k23wr

So did you overlook or miss this one or skip it or what?