Bitcoin puzzle transaction ~32 BTC prize to who solves it

[citb0in]

What exactly makes you think that this case could not occur during the payout process of one of the "puzzles" mentioned here? Just because someone opens a thread on a forum and opens the starting gun for a 32BTC, is that legal? How do you know who the coins originally belonged to and what source they came from? Could also have been created and collected from illegal activities and the puzzle here is a test to see if and how and when someone gets "caught". Suppose it were a case like this: the person who has access to the big safe can't take the coins out because he knows he's not the owner and the mafia bosses and drug lords he'd be stealing from wouldn't speak well of him. So he lets a few "rats" go to the food bowl to see what happens. A rogue who thinks evil

[AliBah]

where i can find the big list of funded btc public keys?

[Easteregg69]

Some times it's hard. !Stylo! Right now!

Cheers.

where i can find the big list of funded btc public keys?

There is some key generator/scanner sites out there. Google.

A machine that generates random keys and check them for funds.

[citb0in]

where i can find the big list of funded btc public keys?

ask LoyceV or search for him. You will find dozens of lists that might meet your expectations. However, read carefully what had already being said. You will waste a lot of resources, just heating your room. Anyway, don't let that stop you from doing whatever you need to do Wish you tons of luck, you might need it. Above all, I wish you lots of fun, a steep learning curve and happy gaining of experience

Cheers

[Easteregg69]

where i can find the big list of funded btc public keys?

ask LoyceV or search for him. You will find dozens of lists that might meet your expectations. However, read carefully what had already being said. You will waste a lot of resources, just heating your room. Anyway, don't let that stop you from doing whatever you need to do Wish you tons of luck, you might need it. Above all, I wish you lots of fun, a steep learning curve and happy gaining of experience

Cheers

The guys talk about immutable and all the sand grains on the beaches and all the stars in the universe for proof.

Your in the blade.

[nomachine]

Just because someone opens a thread on a forum and opens the starting gun for a 32BTC, is that legal? How do you know who the coins originally belonged to and what source they came from?

He is an honorable and honest hacker. Trust me bro™ 

[maylabel]

I removed the space between the private keys.
See how the first 4 digits of the private key are known?
Now guess 66!

https://www.talkimg.com/images/2024/04/23/jWRcT.gif

Astrology for btc... nothing on this gif makes sense. Think about radius, angle, spiraling direction, order. If this is true, do with all the addresses. Can you do with all, not with the last 3 puzzles?

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

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

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

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