Bitcoin puzzle transaction ~32 BTC prize to who solves it

[abeez2000]

Hello friends,

Based on what I have followed and read, I have not found any safe and guaranteed solution for withdrawing funds from any wallet whose private key has been solved.

I kindly ask you, my friends, to share with us what you believe to be the best and safest way to withdraw funds and manage them later in case any puzzle is solved.

It is extremely disheartening for someone to exhaust their energy, resources, and intelligence to solve a puzzle, only for their efforts to be stolen in the blink of an eye.

I believe such an experience would leave someone in lifelong shock.

[benjaniah]

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.

Could you elaborate on this? I noticed a while ago that some people were trying to solve the puzzles by collecting RIPEMD160's hashes of addresses with a certain number of prefix matches, and somehow using that information to generate areas in the puzzle keyspace to scan which (they thought) would have a higher probability of having another address with the same number of prefix matches too. Isn't that the exact same thing as using vanitysearch to find addresses with matching prefixes (i.e. 1BY8GQbnue), and taking the difference between the prefix addresses found to try and find the next/nearest address with the same prefix?

Am I missing something? Is there a more efficient/faster method to search more keys in less time, besides vanitysearch with GPUs? Or is vanitysearch + GPU's already the best available option out there?

Thanks.

[kTimesG]

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.

Could you elaborate on this?

What's to elaborate? You can unfortunately find addresses for which the found prefix (let's say, of length 10) do not all have the same amount of identical leading bits as the target hash.

In short, this breaks any kind of statistical computations, because some prefixes match less leading bits, and some prefixes match more leading bits. On the outside (base58 view) they will all have the same 10 char prefix. Combined with the 50% chance of having any bit of any hash either a 0 or a 1, this is the explanation for bibilgin's latest mystery quiz: why some prefixes are found more often then others. And it's also just another pitfall in his theories, once the issue is actually understood.

Thankfully I didn't need to burn tons of kilowatts to find this out the hard way. Every man eats his own yogurt, or whatever...

[benjaniah]

Hello friends,

Based on what I have followed and read, I have not found any safe and guaranteed solution for withdrawing funds from any wallet whose private key has been solved.

I kindly ask you, my friends, to share with us what you believe to be the best and safest way to withdraw funds and manage them later in case any puzzle is solved.

It is extremely disheartening for someone to exhaust their energy, resources, and intelligence to solve a puzzle, only for their efforts to be stolen in the blink of an eye.

I believe such an experience would leave someone in lifelong shock.

This has been exhaustively discussed in the previous pages of this this forum thread, but to sum it all up:

There is no guaranteed way to withdraw the funds, given that the private key is low entropy. Your best interest would be to not participate, quit while you still can, abandon ship.

Would you work a job where you had to show up every day, putting in all of your energy and resources and intelligence into the job for every shift, day after day, week after week, month after month, perhaps even years, with no guarantee that when the job is actually done, that you might or might not finally get paid? Hope that answers your question.

On the day that puzzle 66 was solved, bitcoin's price was $58,000. Today it's $102,000. If you want to get rich quick, just buy some bitcoin. If you want to become poor quick, keep searching for the keys to the puzzle wallets 

[mjojo]

Your idea sounds exceptional! What are you waiting for, someone to code it, too? Because we all know we can just mix up "Kangaroo software" with whatever else, and jump-scan the range like there is no tomorrow!

People confuse devs with magicians, as if anything is actually possible and we're supposed to make it happen. And when they hear it's not possible, we're the stupid ones, not their ideas. And also, the cost of breaking puzzle 160 at today's GPU hour-rates is around 1 billion dollars, so if anyone has money to burn, I don't know why it wasn't yet solved. There is no need for a new idea for it to be solved, because it can be solved today if someone really wants it to be solved. But they won't use magic, the math is already good enough, but people still think they can beat the correct math by using the wrong math. DM me if you really want your vanity kangaroo software if you don't have nothing to do with your money.

I guess I was misunderstood because I said it as an analogy for the idea.

I am scanning the 67th wallet with the VanitySearch System, and I scanned the 66th wallet before. I hadn't been scanning for a long time due to my work.

I came back because I discovered a few things. In fact, I only confirmed 2 things 100% among the discovered ones, I am working on the other discoveries.

While scanning with VanitySearch, I saw a common point between the wallets I found. I don't want to explain this right now. When everything is finished, I will share it with some people for further development.

In short, the process is as follows, when scanning in vanitysearch, it makes a few jumps when it reaches a certain wallet and continues scanning again, and when it reaches the next certain wallet, it jumps again and scans. The details are with me.

Good work and good luck to everyone.

lets make me clear, did you mean after your script found prefix 1BY8GQbnueY then automatically jump to the next prefix 1BY8GQbnueY?

Sorry if my past question become war about prefixes in this thread.. in puzzle 66 I scanned with sequentialy and found average between prefixs 13zb1hQbWV have distance around 2,750,000,000,000,000 until 3,150,000,000,000,000. So if somebody here have tools or script to jump automatically after found prefix target maybe the chance is bigger to win reward.
*edited : I scanned around 16,000,000,000,000,000 keys with sequentially

[bibilgin]

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?

Congratulations. It doesn't mean anything to me.

Is there any proof of what you said?
Answer=No.

[WanderingPhilospher]

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?

Congratulations. It doesn't mean anything to me.

Is there any proof of what you said?
Answer=No.

Finally, we agree. Prefixes found closer to another one, or at all, don't mean anything, as far as helping one find the actual address.

I just hope you didn't miss it or others, using math and probabilities. If so, you might miss the address with the funds in it.

[pbies]

You can make addresses as many as you like by just encoding some bytes with base58check and changing last of them to encode another address, but this is nonsense when you don't have a private key for these addresses.

[bibilgin]

Finally, we agree. Prefixes found closer to another one, or at all, don't mean anything, as far as helping one find the actual address.

I just hope you didn't miss it or others, using math and probabilities. If so, you might miss the address with the funds in it.

"Prefixes found closer to another one, or at all, don't mean anything, as far as helping one find the actual address."

You say this.

But

Wallet: 1BY8GQbnuec3Vp8YimiL8Bf17UfP1k23wr
Hex: 6F8xxxxx (You don't write this.)

I hope you don't LIE about something like this after scanning that range for a few days and not finding another close HEX code.

[WanderingPhilospher]

Finally, we agree. Prefixes found closer to another one, or at all, don't mean anything, as far as helping one find the actual address.

I just hope you didn't miss it or others, using math and probabilities. If so, you might miss the address with the funds in it.

"Prefixes found closer to another one, or at all, don't mean anything, as far as helping one find the actual address."

You say this.

But

Wallet: 1BY8GQbnuec3Vp8YimiL8Bf17UfP1k23wr
Hex: 6F8xxxxx (You don't write this.)

I hope you don't LIE about something like this after scanning that range for a few days and not finding another close HEX code.

lol, I have no reason to lie.

I did not scan anything, well, recently. I found it on a rig that hasn't ran the 67 challenge in a while. I finally consolidated my list and spotted that one.

You can do what you will with the info. I was just informing you that there is an address closer.

[bibilgin]

lol, I have no reason to lie.

I did not scan anything, well, recently. I found it on a rig that hasn't ran the 67 challenge in a while. I finally consolidated my list and spotted that one.

You can do what you will with the info. I was just informing you that there is an address closer.

Thank you for not giving me information = (Nothing).
If you wanted me to write this, I wrote it.

Now it's up to you to prove it's a LIE or TRUE.
You won't be the first or the last person to say you're closer than me.

My MESSAGE to everyone ;

I really don't understand most of you.

You say you are doing it wrong?
I say prove it. Everyone says things they have memorized.
But you don't think there is a difference of opinion or that we are wrong.

Everyone has calculated how many 66-67 bit, 10 or 11 lengths there are. Nobody knows the right answer. Everyone says an average PROBABILITY result.

When I say something about PROBABILITY, I am declared the person who is doing it WRONG.

SHA1-2, Base58-64, MD, Cyrpt etc. I know all of these, friends. But don't forget that there will be solutions.

[Geshma]

lol, I have no reason to lie.

I did not scan anything, well, recently. I found it on a rig that hasn't ran the 67 challenge in a while. I finally consolidated my list and spotted that one.

You can do what you will with the info. I was just informing you that there is an address closer.

Thank you for not giving me information = (Nothing).
If you wanted me to write this, I wrote it.

Now it's up to you to prove it's a LIE or TRUE.
You won't be the first or the last person to say you're closer than me.

My MESSAGE to everyone ;

I really don't understand most of you.

You say you are doing it wrong?
I say prove it. Everyone says things they have memorized.
But you don't think there is a difference of opinion or that we are wrong.

Everyone has calculated how many 66-67 bit, 10 or 11 lengths there are. Nobody knows the right answer. Everyone says an average PROBABILITY result.

When I say something about PROBABILITY, I am declared the person who is doing it WRONG.

I know all of these, friends. But don't forget that there will be solutions.

------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhArAdMsz8Qy
Hash160: 739437bb3dd6d1983e66629c5f08c70e51db53af
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhFEzGfW5Jd5
Hash160: 739437bb3dd6d1983e66629c5f08c70e524f436c
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhBXaa9CSSoz
Hash160: 739437bb3dd6d1983e66629c5f08c70e51ed4234
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhBREEgoMzYo
Hash160: 739437bb3dd6d1983e66629c5f08c70e51ea5e87
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhGm5ehSbYxs
Hash160: 739437bb3dd6d1983e66629c5f08c70e527757d3

[bibilgin]

------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhArAdMsz8Qy
Hash160: 739437bb3dd6d1983e66629c5f08c70e51db53af
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhFEzGfW5Jd5
Hash160: 739437bb3dd6d1983e66629c5f08c70e524f436c
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhBXaa9CSSoz
Hash160: 739437bb3dd6d1983e66629c5f08c70e51ed4234
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhBREEgoMzYo
Hash160: 739437bb3dd6d1983e66629c5f08c70e51ea5e87
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhGm5ehSbYxs
Hash160: 739437bb3dd6d1983e66629c5f08c70e527757d3

What are you after?
Which of these is in the 67 bit range?
None of them.

What are you aiming for by writing this?
If I told you to write the hex code, you wouldn't know.

[mcdouglasx]

I support what Bibilgin is researching because, after all, it is a technique. There are no exact patterns in the prefixes, that is correct and we all understand that, but it is still a technique. Although we all agree that a prefix could be closer to another than we think, this possibility is much smaller, due to the fact that hashes are made to have a uniform distribution. This could be seen as a foundational argument for this technique.

We all know that the longer the prefix to search for, the larger the number of subsequent jumps for find the next prefix, which is another argument that strengthens this technique.

In the end, it is just another statistical and probabilistic technique, like the birthday paradox, Kangaroo, and many others. And since for address search we only have sequential and random brute force, why would it be wrong to add another technique based on probability? Why always impose a dogmatic conduct?

[WanderingPhilospher]

Now it's up to you to prove it's a LIE or TRUE.
You won't be the first or the last person to say you're closer than me.

Would you like to put a wager on it? 0.1 BTC ?

Also, there is no right or wrong way to search for 67...well the right way to scan is to do 100% scan. I think what some people have said to you, is that you can do what you are doing, but you more than likely, probabilisticly, you will skip over some prefixes; and one of those could be the actual address you are looking for. That's all.
But you double down and talk about how your way is a sure fire way. But I know for a fact, you have missed at least one key.

But I will say this, keep doing what you are doing. You will find the key or you won't.

Why always impose a dogmatic conduct?

I think you are missing the point, the bigger picture or what he is posting and saying and what others counter with.

[Geshma]

------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhArAdMsz8Qy
Hash160: 739437bb3dd6d1983e66629c5f08c70e51db53af
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhFEzGfW5Jd5
Hash160: 739437bb3dd6d1983e66629c5f08c70e524f436c
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhBXaa9CSSoz
Hash160: 739437bb3dd6d1983e66629c5f08c70e51ed4234
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhBREEgoMzYo
Hash160: 739437bb3dd6d1983e66629c5f08c70e51ea5e87
------------------------------------------------------------
Private Key:
Public Key:
Address: 1BY8GQbnueYofwSuFAT3USAhGm5ehSbYxs
Hash160: 739437bb3dd6d1983e66629c5f08c70e527757d3

What are you after?
Which of these is in the 67 bit range?
None of them.

What are you aiming for by writing this?
If I told you to write the hex code, you wouldn't know.

so many different bit ranges can give address that resemble what you are looking for.

[kTimesG]

I support what Bibilgin is researching because, after all, it is a technique. There are no exact patterns in the prefixes, that is correct and we all understand that, but it is still a technique. Although we all agree that a prefix could be closer to another than we think, this possibility is much smaller, due to the fact that hashes are made to have a uniform distribution. This could be seen as a foundational argument for this technique.

Human intuition is wrong, and there are countless experiments that prove this.

The possibility of two keys sharing the same hash exists. Period. Now, human intuition interferes and says "OK, but they can't be so close, right?". Wrong, who says that they cannot?! What is the difference between keys 42 and 43, and keys 42 and whatever other key? No difference. The keys are LABELS, not information that has any statistical relevance.

The probability of whatever pair of two keys you want to pick to have an identical / semi-identical / totally different (pick whatever characteristic and whatever degree you like) is always the same, no matter how many times you repeat the test. The chances do not change just because you are doing the extractions (hashing). Just because you flipped a coin heads 100 times in a row does not mean there are greater chances to have it flip tail on the 101st flip. At most, you can pretend the coin is rigged, but you can never be sure, unless you repeat 100 flips many many times, and aach 100 sequence of flips ends up the same. That is the pattern, and if you can't get a pattern, you definitely can't get statistics to predict the future.

On a very long term, and for very very large sets of data, the averages correspond to the ideal values. But in the real world (lotteries for example, or Puzzle XYZ), the averages and the predictions are only as good as how you measure them to be. By measure, I mean counting all the results, one by one.

You cannot change reality based on probability, it works the other way around: the model of a phenomenon is created based on the observations. So Puzzle 67, all the lotteries in the world, etc. will piss on our human intuition that "no way number 7 was drawn 13 times in a row". You can find lots and lots of anomalies just by analyzing the data, I don't know of any better way for someone to convince themselves, since they will keep saying we're the ones being wrong.

[WanderingPhilospher]

A small size sample test on prefixes.

Using this code:

Code:

import base58
min = base58.b58decode('1BY8GQb111111111111111111111111111').hex()
max = base58.b58decode('1BY8GQbzzzzzzzzzzzzzzzzzzzzzzzzzzz').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 - 41))

print(n)

So for the 6 character prefix of "1BY8GQb", the code says there should be an average of 143.55 prefixes that start with 1BY8GQb, inside a 41 bit range.

I ran two, 41 bit ranges.
1st range = 155 found 1BY8GQb prefixes
2nd range = 145 found 1BY8GQb prefixes

So if one was using some step size / increment size to try and gauge the next 1BY8GQb prefix moving forward with different ranges, by doing some average distance between the prefixes, how would they decide? Which sample range above would they use?

Let's take it one step further, same code, different input:

Code:

import base58
min = base58.b58decode('1BY8GQbn11111111111111111111111111').hex()
max = base58.b58decode('1BY8GQbnzzzzzzzzzzzzzzzzzzzzzzzzzz').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 - 41))

print(n)

So for the 7 character prefix of "1BY8GQbn", the code says there should be an average of 2.47 prefixes that start with 1BY8GQbn, inside a 41 bit range.
Results:
1st range = 4 found 1BY8GQbn prefixes
2nd range = 3 found 1BY8GQbn prefixes

So again, how does one determine a good step / increment size? Take the averages in between found prefixes and then subtract some arbitrary amount, in hopes not to skip over a prefix...the prefix that is actually the full address they are looking for? That's the gamble with this strategy. Is it right or wrong, no. Is it a sure fire way to narrow down the search space and find the address, also no.

The other thing about ripemd160 hashes, you can have the same 40 leading bytes, and have two different address prefixes. Example: 739437BB 3Dxxxxxx  This can create a single difference, or an entire difference. So to me, that's why it's hard to truly get an idea of how many times a prefix may be in a certain size range. We can use some tools and get an idea, but as it's been said, it's just an idea, an average based off of x y and z.

[mcdouglasx]

The probability of whatever pair of two keys you want to pick to have an identical / semi-identical / totally different (pick whatever characteristic and whatever degree you like) is always the same, no matter how many times you repeat the test. The chances do not change just because you are doing the extractions (hashing). Just because you flipped a coin heads 100 times in a row does not mean there are greater chances to have it flip tail on the 101st flip. At most, you can pretend the coin is rigged, but you can never be sure, unless you repeat 100 flips many many times, and aach 100 sequence of flips ends up the same. That is the pattern, and if you can't get a pattern, you definitely can't get statistics to predict the future.

You are talking about each coin flip having a 50% probability of landing on "heads" and a 50% probability of landing on "tails," with no relation to previous results. However, in the scenario you propose, there is a connection. Although each coin flip has a 50% (0.5) probability of landing on "heads" and a 50% (0.5) probability of landing on "tails," when we want to calculate the probability of getting "heads" in consecutive flips, we multiply the individual probabilities:

The probability of getting "heads" in one flip is 0.5, in two consecutive flips is (0.5 \times 0.5 = 0.25), in 100 consecutive flips is (0.5^100), which is an extremely small number.

So, it is not like you think that the probability is always the same. This is known as compound probability, which refers to the probability of multiple independent events occurring in sequence.

I think you are missing the point, the bigger picture or what he is posting and saying and what others counter with.

In that sense, you are right; he cannot ensure whether a prefix is not in a site based on statistics alone.

[bibilgin]

Would you like to put a wager on it? 0.1 BTC ?

Also, there is no right or wrong way to search for 67...well the right way to scan is to do 100% scan. I think what some people have said to you, is that you can do what you are doing, but you more than likely, probabilisticly, you will skip over some prefixes; and one of those could be the actual address you are looking for. That's all.
But you double down and talk about how your way is a sure fire way. But I know for a fact, you have missed at least one key.

But I will say this, keep doing what you are doing. You will find the key or you won't.

I see your 0.1 BTC bet and I say let's increase it. Let's say 0.2 BTC.
Because you are not looking for proof. But I also know you are bluffing.

You can only skip some wallets this way. You want to give information in case you lose your chance.

I know that.

But Random scanning,

Sequential scanning (wasting time),

I am aware that my chances are higher compared to these.

A small size sample test on prefixes.

Using this code:

Code:

import base58
min = base58.b58decode('1BY8GQb111111111111111111111111111').hex()
max = base58.b58decode('1BY8GQbzzzzzzzzzzzzzzzzzzzzzzzzzzz').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 - 41))

print(n)

In such tests, the wallet character length is important. A wallet with a length of 33 is significantly different from a wallet with a length of 34.

So when you calculate in bits, you don't know how many 33 or 34 wallets you have in the bit range you are looking for.