Bitcoin puzzle transaction ~32 BTC prize to who solves it

[kTimesG]

but idk, i had an idea
is there anyways to extend https://privatekeyfinder.io/bitcoin-puzzle/random-keys/66 instead of 50 keys per time, to like idk maybe 500, will reduce by 10.
ik ik, it will maybe takes more time than a normal vanity addresss search

my idea is not only find the 66# puzzle, but maybe if you cross with other wallets with balance if more random wallets can be see at once. Its simple and lite for any pc

You'll need to wait until the end of the galaxy we live in (times many billions) until you stumble upon a key with wallet balance.

[1715237412]

1715237412

[ccinet]

but idk, i had an idea
is there anyways to extend https://privatekeyfinder.io/bitcoin-puzzle/random-keys/66 instead of 50 keys per time, to like idk maybe 500, will reduce by 10.
ik ik, it will maybe takes more time than a normal vanity addresss search

my idea is not only find the 66# puzzle, but maybe if you cross with other wallets with balance if more random wallets can be see at once. Its simple and lite for any pc

You'll need to wait until the end of the galaxy we live in (times many billions) until you stumble upon a key with wallet balance.

You have billions more chances attacking brain wallets

[nomachine]

Astrology for btc...

Some make good money from BTC astrology. But that doesn't work here .

You'll need to wait until the end of the galaxy we live in (times many billions) until you stumble upon a key with wallet balance.

Can you imagine idiots who buying Python scripts to solve this puzzle for billions of years?

Two things are infinite: the universe and human stupidity.

[ccinet]

Astrology for btc...

Some make good money from BTC astrology. But that doesn't work here .

You'll need to wait until the end of the galaxy we live in (times many billions) until you stumble upon a key with wallet balance.

https://i.ibb.co/qxYQz0R/2024-05-02-08-20.png

Can you imagine idiots who buying Python scripts to solve this puzzle for billions of years?

Two things are infinite: the universe and human stupidity.

The Human mind is incapable of understanding such enormous magnitudes, which is why in these cases it is useful to use analogies.
The number space of puzzle 66 is equal to (2^65) -(2^66-1) or 36893488147419103231.
Now suppose that each digit of that number is a millimeter.
The light travels in a year 9460730472580000000 millimeters, so to travel through the space of the 66 puzzle you would need 3.9 ≈ 4 LIGHT YEARS
If we take into account that the closest star is Alpha Centauri, which is 4.2 light years away, the number space in the 66 puzzle would be the equivalent of a ruler in millimeters
SO LONG THAT IT WOULD REACH FROM THE EARTH TO ALPHA CENTURUS.
Randomly Satoshi has hidden 6.6 BTC in that rule... FIND IT!
Here's the challenge!

[nomachine]

Randomly Satoshi has hidden 6.6 BTC in that rule... FIND IT!
Here's the challenge!

When using Pollard's kangaroo algorithm with a known public key, it's like having a warp drive that efficiently navigates through space, jumping through distances equivalent to 3.9 light years, leveraging the known structure provided by the public key.

However, if the public key were unknown, it would be akin to being in an unmapped region of space. Without the reference point provided by the known public key, a program attempting to find the solution would face difficulty in efficiently traversing the vast number space, much like navigating through uncharted space would require exploring the entire area.

So, in summary, the known public key acts as a mapped star system, enabling the algorithm to efficiently navigate through the vast number space of puzzle 66.  

[viljy]

Sometimes I read this thread. That's what I see here for the first time - numerological fortune telling. Well, this can have absolutely nothing to do with the puzzle.
Everything that is known about the puzzle and the ways to solve it can be reduced to such conclusions:
1. The puzzle keys in the range from 2⁰ to 2¹⁶⁰ are not randomly distributed, because they obey the rule - every next key after x₁ in the range 2ⁿ, the value of x₂ is located in the next range 2⁽ⁿ⁺¹⁾.
2. The keys are located randomly inside the ranges. That is why two adjacent keys can be in such extreme positions as xⁿ-1 and xⁿ+1, as well as in positions xⁿ+1 and x⁽ⁿ⁺²⁾-1.

That is, the law of normal distribution does not generally apply to all ranges, but conditionally applies if we consider ranges as separate elements. Indeed, if we take base 2 logarithms from known keys and consider their decimal part (you can multiply by 100% for clarity), then we can see that the location of the keys inside the ranges is closer to the middle. However, the ranges themselves are not equivalent.
This is all that can be accurately noted about the puzzle keys.

What are the possible solutions. For now, let's consider only the case of public keys, since going through addresses is uninteresting and useless, so there are two options:
A. Fast discrete logarithm algorithm. Whether it exists is unknown, just as it is unknown whether the expression P=NP is true. But there are two algorithms that, in a sense, can be considered as such: kangaroo and BSGS, since they reduce the complexity to O(n^1/2).
B. Probabilistic approximation, that is, in other words, a reduction in the search space, where the above algorithms can already be effective, working on reasonable resources, and not on all video cards in the world.

There are two ways to make a probabilistic approximation: searching for a function that reflects a pattern among the distribution of private keys and searching for an approximate discrete logarithm function. The first seems possible, because the keys as a whole are not randomly distributed, but are subordinated to the patterns from paragraph 1. In fact, searching for patterns among already known keys is obviously a dead end option.
The reason for this is a very small sample. If there were 16000 or at least 1600 ranges instead of 160, then this might make some sense. You can set a function that connects certain reference numbers-arguments in ranges (for example, their midpoints) with known keys and approximate the function, but this is a false dependence.
As a result, the task of simplifying the search is to find an approximate function that establishes the relationship between the private key and the public and the further application of the already known algorithms "meeting in the middle" or "birthday attack" (BSGS or kangaroo). There are no other options yet. And these are definitely not magic circles or "solstice of prime numbers" tables.

[albert0bsd]

What are the possible solutions. For now, let's consider only the case of public keys, since going through addresses is uninteresting and useless, so there are two options:
A. Fast discrete logarithm algorithm. Whether it exists is unknown, just as it is unknown whether the expression P=NP is true. But there are two algorithms that, in a sense, can be considered as such: kangaroo and BSGS, since they reduce the complexity to O(n^1/2).
B. Probabilistic approximation, that is, in other words, a reduction in the search space, where the above algorithms can already be effective, working on reasonable resources, and not on all video cards in the world.

I am working in some probabilistic BSGS version it will increase the "probabilistic speed" but since probabilistic means drop some keys with unlikely endings or repeated patterns there is the possibility of a misshit.

There are no other options yet. And these are definitely not magic circles or "solstice of prime numbers" tables.

Yeah aggree with you 100% all those users writing BS should not be here.

[viljy]

I am working in some probabilistic BSGS version it will increase the "probabilistic speed" but since probabilistic means drop some keys with unlikely endings or repeated patterns there is the possibility of a misshit.

First of all, let me express my respect to you for creating an excellent Keyhunt program.
Unlikely key values can be numbers in which there are several (for example, more than three) identical digits in a row? I assume this from the fact that, from the point of view of probability, it is unlikely that there will be at least one key of this kind in the puzzle.

On the other hand, the proportion of such "beautiful numbers" in the search ranges is probably no more than ~ 20%, that is, not very much. But maybe I'm wrong, and you're excluding certain numbers for some other reason.

[Fllear]

I have a question. Maybe someone will help.
How to do it like this.
Let's say the decimal is generated using multiplication. For example, multiply 10 by 2, we get 20 and convert it into a hex, and then into a public key and compare the resulting key with the one we are looking for. For example, you need to set 10 and the number needs to be multiplied from 1 to 10000 and then checked.
So is it possible to implement the script?

[kTimesG]

On the other hand, the proportion of such "beautiful numbers" in the search ranges is probably no more than ~ 20%, that is, not very much. But maybe I'm wrong, and you're excluding certain numbers for some other reason.

I'd say the proportion of "unlikely patterns" in a private key of size n is more like very close to 0.00% (zero percent) the higher n gets. And it goes towards 0 really fast as n grows exponentially.

The amount of the sum of valid distinct combinations when selecting k elements, from a set of n, is massively larger towards the middle (n/2) and the close ranges around the middle, compared to the edges.

And this gap gets tighter and tighter as n increases, resembling a straight up point in the middle, which contains when looking at it with a "microscope" 99.9999% of all the possibilities. Everything else (the 0.00001%) is in the ranges before and after the central point.

This is called the central limit theorem (long-term, all results will be around the average). If this law would be invalid in observation, then it would mean randomness is not part of the structure of the game, and bias of the phenomenon (a fake coin, a compromised dice, non-random generated bits) can be proven with 99.99% certainty, But guess what, we have solutions already found with sequences of eleven consecutive 1 bits, and all the other sorts of sequences of 1 and 0 as well, which if you compute probabilistically, are not at all far away from the statistical model of a randomly generated phenomenon, so...? Excluding patterns just complicates the efficiency of the search, not sure I would play such a gamble (higher bid, lower reward).

[maylabel]

but idk, i had an idea
is there anyways to extend https://privatekeyfinder.io/bitcoin-puzzle/random-keys/66 instead of 50 keys per time, to like idk maybe 500, will reduce by 10.
ik ik, it will maybe takes more time than a normal vanity addresss search

my idea is not only find the 66# puzzle, but maybe if you cross with other wallets with balance if more random wallets can be see at once. Its simple and lite for any pc

You'll need to wait until the end of the galaxy we live in (times many billions) until you stumble upon a key with wallet balance.

My man, I know very, very ,very well math and statistics. Better than you think.
however I dont have gpu, a soly laptop, doing 3000 others tasks in parallel and almost with not space.

Im not a neck beard in a mom's basement with an entire day and money to spend on gpu

Today i tried unsuccessully install keyhunt. IDK if have another good for mac

I'm calculating by hand to shrink the range, i'm using this https://privatekeys.pw/scanner to scanning.
But idk if I can trust in case if I found

[maylabel]

On the other hand, the proportion of such "beautiful numbers" in the search ranges is probably no more than ~ 20%, that is, not very much. But maybe I'm wrong, and you're excluding certain numbers for some other reason.

I'd say the proportion of "unlikely patterns" in a private key of size n is more like very close to 0.00% (zero percent) the higher n gets. And it goes towards 0 really fast as n grows exponentially.

The amount of the sum of valid distinct combinations when selecting k elements, from a set of n, is massively larger towards the middle (n/2) and the close ranges around the middle, compared to the edges.

And this gap gets tighter and tighter as n increases, resembling a straight up point in the middle, which contains when looking at it with a "microscope" 99.9999% of all the possibilities. Everything else (the 0.00001%) is in the ranges before and after the central point.

This is called the central limit theorem (long-term, all results will be around the average). If this law would be invalid in observation, then it would mean randomness is not part of the structure of the game, and bias of the phenomenon (a fake coin, a compromised dice, non-random generated bits) can be proven with 99.99% certainty, But guess what, we have solutions already found with sequences of eleven consecutive 1 bits, and all the other sorts of sequences of 1 and 0 as well, which if you compute probabilistically, are not at all far away from the statistical model of a randomly generated phenomenon, so...? Excluding patterns just complicates the efficiency of the search, not sure I would play such a gamble (higher bid, lower reward).

Really depends

In the grim reality, the problem is most of randomization in computer level are not real random.
We suffer this problem a lot in my area where what should be random always have a bias or a preference.

Now coupling that with a codes with more than 10 years old code who may has more rudimentary random generations comparing with modern scripts....
I worked 15 years ago with similar code generators.... and yet, we saw prevalence in some number generation, clusters and sequences, even if you use different seeds, some numbers where significant more prevalent than others.


That's why I'm doing the calculation by hand, I can see more clear patterns arising and reducing the range.
It will take a while, maybe, idk sincerely, but I want to try another route bc I don't have a GPU 


Another point is not having a pool of checked addresses.

So, is we think code like bitcrack or keyhunt have also "random", chances are, in a long run with enough computers, we are double-checking some addresses, losing time and computer power in the process.

Can be small headache, but as an example of that: on https://privatekeys.pw/scanner you can see have several people with more than a trillion addresses checked.
The caveat is many times will be in sequential mode for puzzle 66;aka recheck the same first addresses over and over.

My perspective of this challenge is to prove with the extended public key + child private key you can discover all keys.
However we are going by brutal force, and as a mathematician, i prefer to be more in a elegant way even if takes more time... and that's why i'm trying to resolve this puzzle

[Tepan]

| 38F6219EE3A3D85D4 | 13zb1P1kw3PyhCiwD3UNpD84fx2axrJhdv   | 20d4593f55c6ad7c26ec814666fce11c74c26240 |
| 22EB598FC469C5C0C | 13zb1WBV2Z48YuUnqEeSMa3a5P4GTMNBXw   | 20d459b3e617ee5b2f4a0ade3489c74e18ae6726 |
| 31D5E00B519D1D343 | 13zb1cs4B4gNiq87JnSNub9o51qtvFFE6G   | 20d45a2091876e79ea6a59f6702d6541b46887a2 |  
| 20C79DCD75513ADA1 | 13zb1iQ3mvS8s4JxBfrT4VU3Kct49jR8z2   | 20d45a7a920ba6f3362cfc5a9a708b717947f31a |
| 340FAE4332F3F93F3 | 13zb1au9kvqRGr497sGb3hoY11NdtZTzHo   | 20d45a00a1a6976e5b3a70ac3ec54387495f799b |
| 3CD7796DC62D738D6 | 13zb1BJZdLWFXnY8opAHtC7tEYKuAx7UY6   | 20d45880e5f2775bef64b160083c7f70ad4e4a2b |
| 3C661DD146906999C | 13zb14dzagJSAs8ExAxiVURvK4hxHGBSvr   | 20d45814826a5130c6b6e99846eefb7b29b08966 |
| 2570B465E2E2B7539 | 13zb1gj8kjC8BcPiLQchHiUYCP7whomxQK   | 20d45a5f65a8db614542cb063ba508920e8294c7 |
| 3512F971A039784C3 | 13zb111npnaATyQibmmhyGo4gyBBgLcB2g   | 20d457d9924eb254900aab37b690f42e3794deb3 |
| 2E4115FFD6DED498D | 13zb1NJoKk8QNVq39ovmvmTP6Qczi6QdEN   | 20d45933d9cd875940a19674e419891c4e1965e7 |
| 2FC3BE3D049B93B5C | 13zb1df5wTfUxc8DCE2FguuX9HRqniUvrj   | 20d45a2d798a79492525fb7c58802c00c99f3c7d |
| 273FD355C07294A64 | 13zb1MeqFdsnQgszDHxyaVLGBmjXL5ikQo   | 20d45929349816c3327f2be99df4595f1653538b |
| 200DAE45EAC5DF2A5 | 13zb16nndRPtF5z6W253AaJ8tmyb2M9hrf   | 20d458377ffaa3c1fb8b5f38d8ae0a1b1a759d15 |
| 28CA317317998B18B | 13zb11DtFvnKEDqSCc1KEMMj6xo16QxFHc   | 20d457dcf660bc47dcd9e54b6fbc36d90a239338 |
| 34E3010DE01C74869 | 13zb1JNs7GtHcpxLEdjhGq6mxnGSHga37d   | 20d458f3f0e8de9ae3711ddbcb843f506dbe7197 |
| 219478B3A52F0735F | 13zb1qhSuRqytgNHBU4aZ2WRNhjVURarVf   | 20d45af1491f5d903895555f040353db14414ed3 |
| 2355254DEE6FCDFF6 | 13zb1yUcbaQfieXJ74pKCZaH4CWiD5bkf2   | 20d45b6fc960b83900f812c21028e77c3da9e126 |
| 3A41C7D979F1BAC9D | 13zb1hidRcTS6S737V8FT5PfazHTU4oX2f   | 20d45a6f84891560f096a6726eeae68fe51277dc |
| 3AA5DA3B2B0279D80 | 13zb14sfH99jTZKTwVvtavCpheZ5fZjGrV   | 20d45818576e6483f52ea575422e2b80a5683f7b |
| 250F27D26FF94B3CA | 13zb1VotqWUouo7HmtaatUKcFsMtv6tkJk   | 20d459add86cbcb25a1d8fbd0db2cf62365b3d04 |

wish me luck, current speed is 100K keys per sec.


just currently update my progress, because i rarely active since i need someone help to translate my rust code into C++.

[nomachine]

wish me luck, current speed is 100K keys per sec.

No luck here.

[ccinet]

wish me luck, current speed is 100K keys per sec.

It must be a joke! You're joking, aren't you?

[abdenn0ur]

wish me luck, current speed is 100K keys per sec.

100kk/s is very low. 
You're better off using keyhunt by alberto
You may get +1Mk/s even on a potato CPU

[Tepan]

wish me luck, current speed is 100K keys per sec.

It must be a joke! You're joking, aren't you?

😂🥶🤫

[Tepan]

wish me luck, current speed is 100K keys per sec.

100kk/s is very low. 
You're better off using keyhunt by alberto
You may get +1Mk/s even on a potato CPU

Nice info, but i already know from year past about that Alberto's BSGS.

[viljy]

I'd say the proportion of "unlikely patterns" in a private key of size n is more like very close to 0.00% (zero percent) the higher n gets. And it goes towards 0 really fast as n grows exponentially.

You and I are probably talking about different things. I mean, it is extremely unlikely that among the remaining undisclosed keys there are patterns such as ffff or 8888 or more repetitions of the same digits.
At the same time, I doubt that such combinations as, for example, c5ec5e or dd4dd4, etc., can be considered unlikely. Therefore, I think it is possible to discard numbers containing patterns of more than three identical digits.
Without any calculations, I roughly assumed that there could not be more than 20% of such numbers in the range.

[maylabel]

I'd say the proportion of "unlikely patterns" in a private key of size n is more like very close to 0.00% (zero percent) the higher n gets. And it goes towards 0 really fast as n grows exponentially.

You and I are probably talking about different things. I mean, it is extremely unlikely that among the remaining undisclosed keys there are patterns such as ffff or 8888 or more repetitions of the same digits.
At the same time, I doubt that such combinations as, for example, c5ec5e or dd4dd4, etc., can be considered unlikely. Therefore, I think it is possible to discard numbers containing patterns of more than three identical digits.
Without any calculations, I roughly assumed that there could not be more than 20% of such numbers in the range.

True, this is another pattern

but has something i found yesterday. I sincerely just want to have some code to run in Mac.

Any one knows a code for mac? Python?

thx in advance