Bitcoin puzzle transaction ~32 BTC prize to who solves it

[bibilgin]

I would not trade ranges with you because you are not doing full ranges. It seems you are looking at prefixes found, then skipping ahead by x amount, based on your mathematical probabilistic.
Ranges do not mean prefixes. Make sense?

I'm not worried about ktimesg, because I agree with him.

Yes, you can say a prefix of x amount length, is found on average, every x amount of keys, and skip ahead after finding one. But then you have to rely on if your skip size was too large.

All good, all I am saying is if you give anyone a starting hex, they can tell you the closest prefix to it, after running some hashes towards it.

"I won't trade intervals with you because you don't do exact intervals. You seem to be looking at the prefixes found and then jumping forward by x amount of time based on your mathematical probabilities.
Intervals don't mean prefixes. Does that make sense?"

I didn't ask for intervals, I asked you to tell me the hex code of the wallet you said was close. (I don't have any other prefixes to change.) Because most of yours are below the 6A-6B start, so they're useless to me.

"I'm not worried about Ktimesg because I agree with it."

You say that and say that, "I don't have these wallets/prefixes because I think they'll show me a pattern." and you say that. That's what I did anyway. There's no other 1BY8GQbnue prefix among the 2 Hex (Wallets) I wrote.

I don't want to explain more about the subject. Because the pattern you're thinking of is a PROBABILITY calculation. It's not a fixed numerical loop.

Good luck my friend, stay healthy.

[WanderingPhilospher]

I would not trade ranges with you because you are not doing full ranges. It seems you are looking at prefixes found, then skipping ahead by x amount, based on your mathematical probabilistic.
Ranges do not mean prefixes. Make sense?

I'm not worried about ktimesg, because I agree with him.

Yes, you can say a prefix of x amount length, is found on average, every x amount of keys, and skip ahead after finding one. But then you have to rely on if your skip size was too large.

All good, all I am saying is if you give anyone a starting hex, they can tell you the closest prefix to it, after running some hashes towards it.

"I won't trade intervals with you because you don't do exact intervals. You seem to be looking at the prefixes found and then jumping forward by x amount of time based on your mathematical probabilities.
Intervals don't mean prefixes. Does that make sense?"

I didn't ask for intervals, I asked you to tell me the hex code of the wallet you said was close. (I don't have any other prefixes to change.) Because most of yours are below the 6A-6B start, so they're useless to me.

"I'm not worried about Ktimesg because I agree with it."

You say that and say that, "I don't have these wallets/prefixes because I think they'll show me a pattern." and you say that. That's what I did anyway. There's no other 1BY8GQbnue prefix among the 2 Hex (Wallets) I wrote.

I don't want to explain more about the subject. Because the pattern you're thinking of is a PROBABILITY calculation. It's not a fixed numerical loop.

Good luck my friend, stay healthy.

Now I know why people are starting to doubt what you say lol.

"..in case I wanted to swap ranges with someone down the road"
Okay send a private message. (But I'm sure you won't.)

How did you not ask me? And stop changing what the hell I said lol. I never said intervals, I said ranges:

I would not trade ranges with you because you are not doing full ranges.

Also, did you not read what I said? I have prefixes all through out the entire range, 40 through 7F.

Everyone knows exactly what you are doing. It may work out for you, and it may not. But you seem to be only searching in a specific range of like 6B to 7D or something. So hopefully the key is there for you.

[bibilgin]

Also, did you not read what I said? I have prefixes all through out the entire range, 40 through 7F.

Everyone knows exactly what you are doing. It may work out for you, and it may not. But you seem to be only searching in a specific range of like 6B to 7D or something. So hopefully the key is there for you.

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

"Every brave man eats yogurt differently." I have said this a few more times.

1BY8GQbnueq2o7rhTM9rT6utJUVeGSxvhF wallet, you may not give the HEX code. You do not need to write anything else for this. It is enough to say it clearly.

If you wish, I can send you a few more HEX codes with the prefix 1BY8GQbnueY. Maybe it will help with your pattern.

I am long past the age of trying to understand people. Because what you do and what I do are similar. But I do not want to scan the unnecessary range. That is the only difference.

The English translation may be wrong again, we may be misunderstanding each other. As a result, it seems like it would be a mistake to give you the real information. You do not want to understand or agree.

[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