Bitcoin puzzle transaction ~32 BTC prize to who solves it

[teguh54321]

By trying to be right, you're being silly. Your craps simulation is correct for that specific game, but it doesn't model prefix pruning. With prefixes, we abort at the first false positive without betting on future events. The probability of success is 63.2%, as my simulations demonstrate. You still fail to distinguish between sequential processes with aborts (prefixes) and conditional bets (your dice).

You inadvertently demonstrate that when you change the rules, the probability changes.

This validates my claim that "Every stopping criterion changes the probability of success."

Prefix pruning: 63.2%

Random stopping: 50%

Your craps bet: 48.2%

Dude, my craps bet (which is actually yours) is exactly what you described as "natural to bet that 6 doesn't appear again in 4 rolls". So if there's anything crappy about it, it was your original statement, which was proven to be false. If you happen to find something's wrong with it, please let me know and I'm happy to refactor it according to your conditionals or whatever. But the results will be identical, since it's simply empirical proof that in whatever 4 rolls (sequential, skipped, timed out and resumed, changing the dice, etc etc etc), any value has a 51.8% chances of showing up at least once. Conditionals are irrelevant, just like skipping is irrelevant. I think you should be the one to go back to the drawing board here.

If you have some other statement about something, or you discover what's wrong with the simulations (not flakes of snow) let me know. Congrats on discovering and demonstrating that there's a 63% chance of success to hit X at least once, when p=1/N, in N tries, btw. No one really bothered to do the math on that one. You're definitely the first.

Forget it, this guy’s ego is so inflated he never even considered that if prefix search actually worked or had any real merit, academics would’ve published on it by now. But there’s nothing because it’s just hot air. You can use any kind of filtering you want, but without the public key, you’ll still end up brute-forcing every private key anyway. In fact, its so-called "prefix search" just makes things less efficient. Good luck to him on his impossible quest.

What about prefix jump ? Example after find  1PWo3JeBthen prefix then jump 1-3  trilion key ...

Mybe have to test safe jump range and how many prefix digit.  

Seems the aaaa bbbb filtering only reduce less than 2% 🙃. Now im focusing on finding sample range from quadrilion of keys to consider the safe jump range

[kTimesG]

What about prefix jump ? Example after find  1PWo3JeBthen prefix then jump 1-3  trilion key ...

Mybe have to test safe jump range and how many prefix digit.  

How about this: instead of jumping, simply continue scanning, but subtract whatever jump size you intended to make (those 1-3 trillion) from the total number of keys you want to look at.

Same thing, but faster. You're welcome. If you get any statistical difference to actually skipping, congrats, you broke the last 300 years of understanding of mathematics^1,2,3,4.

¹ assuming the secp256k1 curve isn't rigged
² assuming SHA256 isn't rigged
³ assuming RIPEMD-160 isn't rigged.
⁴ assuming your programming language isn't rigged.

[Virtuose]

What about prefix jump ? Example after find  1PWo3JeBthen prefix then jump 1-3  trilion key ...

Mybe have to test safe jump range and how many prefix digit.  

Seems the aaaa bbbb filtering only reduce less than 2% 🙃. Now im focusing on finding sample range from quadrilion of keys to consider the safe jump range

Filtering doesn’t actually reduce the work in this context because you still have to find the correct value before you can filter it. It’s like claiming you can pick winning lottery tickets faster by throwing out the losing ones, but you still have to check each ticket to know if it’s a winner. With private keys, unless you already have extra information (like a public key prefix that actually leaks some useful bits), every candidate has to be generated and checked in full. Filtering after the fact doesn’t magically cut down the number of computations, it just adds an unnecessary layer. You can only filter something once you’ve already done the work to find out if it matches or not so there’s no real gain.

[teguh54321]

What about prefix jump ? Example after find  1PWo3JeBthen prefix then jump 1-3  trilion key ...

Mybe have to test safe jump range and how many prefix digit.  

Seems the aaaa bbbb filtering only reduce less than 2% 🙃. Now im focusing on finding sample range from quadrilion of keys to consider the safe jump range

Filtering doesn’t actually reduce the work in this context because you still have to find the correct value before you can filter it. It’s like claiming you can pick winning lottery tickets faster by throwing out the losing ones, but you still have to check each ticket to know if it’s a winner. With private keys, unless you already have extra information (like a public key prefix that actually leaks some useful bits), every candidate has to be generated and checked in full. Filtering after the fact doesn’t magically cut down the number of computations, it just adds an unnecessary layer. You can only filter something once you’ve already done the work to find out if it matches or not so there’s no real gain.

Hmm but im against this. From what i discover now. Some long adress prefix actually have some significant distance between them.  

I can skip trilions of key before continue brute force .  And yes there a chance of missing it if the skip to far away. now im gathering bout quadrilions of keyspace and look the lowest distance between those prefix. And only skip half of the lowest distance that i discover  , so it will be consider safe skip

[Virtuose]

What about prefix jump ? Example after find  1PWo3JeBthen prefix then jump 1-3  trilion key ...

Mybe have to test safe jump range and how many prefix digit.  

Seems the aaaa bbbb filtering only reduce less than 2% 🙃. Now im focusing on finding sample range from quadrilion of keys to consider the safe jump range

Filtering doesn’t actually reduce the work in this context because you still have to find the correct value before you can filter it. It’s like claiming you can pick winning lottery tickets faster by throwing out the losing ones, but you still have to check each ticket to know if it’s a winner. With private keys, unless you already have extra information (like a public key prefix that actually leaks some useful bits), every candidate has to be generated and checked in full. Filtering after the fact doesn’t magically cut down the number of computations, it just adds an unnecessary layer. You can only filter something once you’ve already done the work to find out if it matches or not so there’s no real gain.

Skipping large key ranges based only on prefix distance is fundamentally flawed. There’s no guarantee the target isn’t in those skipped ranges. It’s not about distance, it’s about coverage, Bitcoin keys are uniformly distributed, so skipping based on superficial patterns will always risk missing the correct key. That’s why no serious cryptographer uses such methods but of course you can try your luck ^^

[fixedpaul]

Hmm but im against this. From what i discover now. Some long adress prefix actually have some significant distance between them.  

I can skip trilions of key before continue brute force .  And yes there a chance of missing it if the skip to far away. now im gathering bout quadrilions of keyspace and look the lowest distance between those prefix. And only skip half of the lowest distance that i discover  , so it will be consider safe skip

What you're discovering is simply how elements are distributed in a uniform distribution. You could search for prefixes across the entire space by jumping randomly, then calculate the distances between the prefixes using the jump index (instead of using the private key), you would get the same results (assuming the hash functions aren't rigged).

The further you go with your search for the "minimum distance", the more likely you are to find two close prefixes, and your "safe jump" will keep getting smaller

What you're doing is like trying to find the ace of hearts in a deck of 52 cards, and skipping 5 cards if you find an ace of another suit, because on average the distance between adiacent aces in a shuffled deck is around 10.6

[teguh54321]

Hmm but im against this. From what i discover now. Some long adress prefix actually have some significant distance between them.  

I can skip trilions of key before continue brute force .  And yes there a chance of missing it if the skip to far away. now im gathering bout quadrilions of keyspace and look the lowest distance between those prefix. And only skip half of the lowest distance that i discover  , so it will be consider safe skip

What you're discovering is simply how elements are distributed in a uniform distribution. You could search for prefixes across the entire space by jumping randomly, then calculate the distances between the prefixes using the jump index (instead of using the private key), you would get the same results (assuming the hash functions aren't rigged).

The further you go with your search for the "minimum distance", the more likely you are to find two close prefixes, and your "safe jump" will keep getting smaller

What you're doing is like trying to find the ace of hearts in a deck of 52 cards, and skipping 5 cards if you find an ace of another suit, because on average the distance between adiacent aces in a shuffled deck is around 10.6

Hmm interesting argument on card 😅.  But from i discover several long prefix in puzzle 50 -63 . The lowest distance still trilionss.  Mybe it worth try 🙃.  Or might the hash litte bit rigged?...  some how not so distributed  ?
But the probability of long prefix over 15 digit below 5 trilion range i think so low ?  🤔

Or anyone here had discover  15 digit prefix with distance below 5 trilion private key range ? 🤔

Btw im modding your code 😅🙏🙏, just hoping my idea works haha.

[kTimesG]

Or might the hash litte bit rigged?...  some how not so distributed  ?
But the probability of long prefix over 15 digit below 5 trilion range i think so low ?  🤔

Or anyone here discover  15 digit prefix with distance below 5 trilion private key range ? 🤔

The hash's rigged.

There is no way that, with whatever 15 digits prefix, you'll ever find two private keys on secp256k1, right next to each other, having a common 15 digit base58 prefix in address.

Is this what you wanted to hear? If so, learn that it's wrong, and it's basically a certainty that with any 15 digit prefix you choose, somewhere on the curve, there will be 2 adjacent keys sharing that address prefix.

15 digits ~= 88 bits

Chance to find 2 in a row: once in ~176 bits

Curve order: ~256 bit.

[teguh54321]

Or might the hash litte bit rigged?...  some how not so distributed  ?
But the probability of long prefix over 15 digit below 5 trilion range i think so low ?  🤔

Or anyone here discover  15 digit prefix with distance below 5 trilion private key range ? 🤔

The hash's rigged.

There is no way that, with whatever 15 digits prefix, you'll ever find two private keys on secp256k1, right next to each other, having a common 15 digit base58 prefix in address.

Is this what you wanted to hear? If so, learn that it's wrong, and it's basically a certainty that with any 15 digit prefix you choose, somewhere on the curve, there will be 2 adjacent keys sharing that address prefix.

15 digits ~= 88 bits

Chance to find 2 in a row: once in ~176 bits

Curve order: ~256 bit.

Okay how bout 10 digit ?
So do you think my idea..
Brute...  if find prefix ... skip  ... trlion key and continue brute.. repeat .. is feseable or not ? 😅🙏

[farou9]

When making a bloomfilter for the x points of scalars 1...2**30 , what is the best hashing algorithm to use to get the lowest false positives candidates possible ?

[GTX1060x2]

When making a bloomfilter for the x points of scalars 1...2**30 , what is the best hashing algorithm to use to get the lowest false positives candidates possible ?

The X coordinate itself is a good source of randomness, you don't need additional hash functions.

Code:

h1 = hash & 2**32 - 1
h2 = hash >> 32 & 2**32 - 1
h3 = hash >> 64 & 2**32 - 1

You will get 3 32-bit numbers.
Adjust the percentage of false positives by the size of the filter and the number of bits per record (hash functions).

[Bram24732]

When making a bloomfilter for the x points of scalars 1...2**30 , what is the best hashing algorithm to use to get the lowest false positives candidates possible ?

Use x as an input.
This will give you the number of hash functions you need based on desired false positive rate.
https://hur.st/bloomfilter/

[ExernalVN]

I mean these prefixes.



1PWo3JeB9jNkTL28QqVi3EvU93LJuZa4JR
1PWo3JeB9jP8jxGWV1eAGXThNbxEhtxuq4
1PWo3JeB9jPUEeDgSsBmZV2oxdmYtogaMX
1PWo3JeB9jRLz2NjTHsZ8uTBnqcjnu66Ak
1PWo3JeB9jS1ttWtFXgTCy2hnCYcW1dD6V
1PWo3JeB9jSUU4ueEp5sSK6i9P26yBWfJh
1PWo3JeB9jSVntJs1FpYM2iTNAoADNv2YD
1PWo3JeB9jSiimGHNbZUoc9hfVe9Ko5SGr
1PWo3JeB9jT926gmLys26TBwr6pwStgwLb
1PWo3JeB9jUAfYHTXQjUYuS6timskdRieF
1PWo3JeB9jUiESdtipzxqWJWTANVYiydnN
1PWo3JeB9jV9ZdU1LBAwHodBvV8fRZdZ1w
1PWo3JeB9jVxkSLg1WgymVexXayVHeBGSM
1PWo3JeB9jVyFtMXcuR7ffrdPkNSLgsePc
1PWo3JeB9jY39MsnvSJSVCdaJegFQzxvzV
1PWo3JeB9jZt9nTjxVcQu2aNrNwEenZcjG
1PWo3JeB9jdMGJNFxwckqgV7HxyrRxWL9R
1PWo3JeB9jddiHUfRfYqBAVjd6HRMEoycu
1PWo3JeB9jdv1SaFoJK7SynTq94JFdbagU
1PWo3JeB9jdvp56gzG8navJjUMFQxxb997
1PWo3JeB9jeFuotNeYDrWkEhqyZ359abB2
1PWo3JeB9jgFbdXaZG1h8ng9hpYzg3CAPw
1PWo3JeB9jgLYkm8cEj6yywPn3kk41BFaY
1PWo3JeB9jgfLmhDhuZofG3Gzfzd5FzBvU
1PWo3JeB9jgfLmhDhuZofG3Gzfzd5FzBvU

Provide the HEX values

0x51c34859a33f9aef08 1PWo3JeB9jNkTL28QqVi3EvU93LJuZa4JR
0x5b4ea19e845df8dc31 1PWo3JeB9jP8jxGWV1eAGXThNbxEhtxuq4
0x549778cd7b98124c10 1PWo3JeB9jPUEeDgSsBmZV2oxdmYtogaMX
0x649a103b78b3e74856 1PWo3JeB9jRLz2NjTHsZ8uTBnqcjnu66Ak
0x649a0ad2d9876795c4 1PWo3JeB9jS1ttWtFXgTCy2hnCYcW1dD6V
0x51da1e8db3710da999 1PWo3JeB9jSUU4ueEp5sSK6i9P26yBWfJh
0x649ade9933e47de861 1PWo3JeB9jSVntJs1FpYM2iTNAoADNv2YD
0x651c1bd5cef37d5b35 1PWo3JeB9jSiimGHNbZUoc9hfVe9Ko5SGr
0x649a05d73d20978e62 1PWo3JeB9jT926gmLys26TBwr6pwStgwLb
0x6518732b2b56b3697c 1PWo3JeB9jUAfYHTXQjUYuS6timskdRieF
0x54add2baaad428adc5 1PWo3JeB9jUiESdtipzxqWJWTANVYiydnN
0x520da9a70715947fbe 1PWo3JeB9jV9ZdU1LBAwHodBvV8fRZdZ1w
0x65a6144aea3216f036 1PWo3JeB9jVxkSLg1WgymVexXayVHeBGSM
0x4620ed669f1b496ec2 1PWo3JeB9jVyFtMXcuR7ffrdPkNSLgsePc
0x7c270c663877b2616c 1PWo3JeB9jY39MsnvSJSVCdaJegFQzxvzV
0x5485e6ee348118068c 1PWo3JeB9jZt9nTjxVcQu2aNrNwEenZcjG
0x40174800c9c91ea596 1PWo3JeB9jdMGJNFxwckqgV7HxyrRxWL9R
0x542234dd5176d05a5f 1PWo3JeB9jddiHUfRfYqBAVjd6HRMEoycu
0x63f651bb9c47645cd6 1PWo3JeB9jdv1SaFoJK7SynTq94JFdbagU
0x649a3dd0486c96e70b 1PWo3JeB9jdvp56gzG8navJjUMFQxxb997
0x649a737f258abb8058 1PWo3JeB9jeFuotNeYDrWkEhqyZ359abB2
0x649af9e3471ed5c49b 1PWo3JeB9jgFbdXaZG1h8ng9hpYzg3CAPw
0x649aa0a809fe13a924 1PWo3JeB9jgLYkm8cEj6yywPn3kk41BFaY
0x7c26f7d7a330e3cf99 1PWo3JeB9jgfLmhDhuZofG3Gzfzd5FzBvU
0x7c26f7d7a330e3cf99 1PWo3JeB9jgfLmhDhuZofG3Gzfzd5FzBvU

this keys was found by prefix using VanityGen ? how to set the range for vanityGen ?

[kTimesG]

15 digits ~= 88 bits

Chance to find 2 in a row: once in ~176 bits

Curve order: ~256 bit.

Okay how bout 10 digit ?
So do you think my idea..
Brute...  if find prefix ... skip  ... trlion key and continue brute.. repeat .. is feseable or not ? 😅🙏

🚀 Go for it. Scanning 3000 trillion keys just to get to a 10-char match, and then skipping 1 trlion keys. Totally feseable and you save on the energy bill too. But why not skip 10 trlion? Or 100 trlion? Ouch, at some point the calculation precision of the events likely to happen starts to not show up as "0.0000000% chances of this shit ever to be seen"? Well, I guess that might mean there is no safe jump size, except maybe a jump of 1 (go to next key). Otherwise, it's as scientific as playing hide and seek.

[Henark]

The strategic recommendation for any serious effort to solve the remaining keys of the puzzle is the adoption of a co-design approach. It is necessary to abandon the pursuit of a purely algorithmic solution and instead simultaneously optimize the attack algorithm for parallelization and the HPC infrastructure for the specific communication patterns that this algorithm generates. The combination of a robust generic attack such as Pollard’s Rho, potentially accelerated by tools like ECFFT, and executed on a specialized and cost-effective network topology like HammingMesh, represents the most promising and economically viable path to completing this puzzle.

Your idea to use the co-design approach for algorithm and hardware is completely clever. Combining Pollard's Rho with tools like ECFFT and implementation on a specialized infrastructure like HammingMesh could theoretically offer high performance. The HammingMesh topology is not yet established and its practical implementation might be complex and expensive. The cost and development time of such a system are likely higher than more common methods like GPU clusters. It is unclear exactly how much performance improvement will be achieved, as algorithmic details and scalability have not been provided. Overall, your approach is creative, but to be feasible both financially and technically, it needs operational analysis and precise benchmarking.

The unsolved Bitcoin puzzles take on a new and profound significance. They act as the ultimate quantum "canary in the coal mine." The sudden solving of a high-numbered puzzle, for instance, one in the 120- to 160-bit range, which is far beyond the reach of classical computation long before classical projections would allow, would be an unambiguous and public signal that cryptographically relevant quantum computing has arrived. Such an event would not just be the claiming of a BTC prize; it would be a shot across the bow for the entire digital security industry, signaling that the era of public-key cryptography as we know it is coming to an end.  

In conclusion, Bitcoin puzzles are far more than games. They are a living legacy of early Bitcoin culture, a testing ground for cutting-edge cryptography, and a continuous demonstration of the principles that underpin decentralized systems. They represent a captivating race between the ever-increasing power of classical computation and the theoretical promise of quantum computing. As long as they remain unsolved, these digital treasures serve as a silent reminder of the strength of Bitcoin's cryptography and as a tantalizing prize for whoever can be the first to crack their secrets whether through brute force, algorithmic ingenuity, or a quantum leap into a new era of computation.

[Mr-M]

I guess that the reason is to prove they know the private key. I guess that it was found by the large collider
thing, since, from what I know, they ask only for a % of the money after "cracking" the private key of a wallet.

As far as I know the "author" of this puzzle-transaction is unknown.
Whom are you asking?

I know.
I just tried to give some sort of reasoning behind what could mean that self-sending of those funds.
Anyone with a better idea is most welcome to share it

Bitcoin is a virtual currency, it has a high level of security, in addition, it also has a freedom, so we can not find out who sent the funds. That is a good thing, but it is also a disadvantage to bitcoin. And I think the author of those deals does not matter, the main thing is that you can get rewards from it.

I think I completed the puzzle but its suddenly gone. When I broadcasted it omg i work my ass of to get it even the time changed!

[HABJo12]

I guess that the reason is to prove they know the private key. I guess that it was found by the large collider
thing, since, from what I know, they ask only for a % of the money after "cracking" the private key of a wallet.

As far as I know the "author" of this puzzle-transaction is unknown.
Whom are you asking?

I know.
I just tried to give some sort of reasoning behind what could mean that self-sending of those funds.
Anyone with a better idea is most welcome to share it

Bitcoin is a virtual currency, it has a high level of security, in addition, it also has a freedom, so we can not find out who sent the funds. That is a good thing, but it is also a disadvantage to bitcoin. And I think the author of those deals does not matter, the main thing is that you can get rewards from it.

I think I completed the puzzle but its suddenly gone. When I broadcasted it omg i work my ass of to get it even the time changed!

    what do you mean by that ? inbox me

[kTimesG]

Using Hamming negative adaptive bias with cross-over population HoF ascension for delta weight minimization, this came up.

Code:

H160: f6f5c31d0c8bf7b52eab7d9ae461071127a0b7e8

 SHA: 44dd2e31a54c0934144c03169c3594f8384fb942491571b1ce17ef81272356a9

132 bits matched, 16 leading. That's around 62.2 bits of classical difficulty.

Let's see if anyone can find the key.

Code:

13BSwDFachETtwunbnmNrRpdNt1Hp8cipS
Found by kTimesG; x = f(y**2)
IPEdHGDZwGFpxiwzmMll6wEDFWtlFCEHnKu7e53EEhwGZdtM3sPDdZWmy0saVsdu8Kqu5fERrtkvlcUZ59u2WSs

[cctv5go]

Share a prefix:
1PWo3JeB9jTm84otLWfm4ePF9x7e1gc81S
5FC34BED98D3286F62

[teguh54321]

Using Hamming negative adaptive bias with cross-over population HoF ascension for delta weight minimization, this came up.

Code:

H160: f6f5c31d0c8bf7b52eab7d9ae461071127a0b7e8

 SHA: 44dd2e31a54c0934144c03169c3594f8384fb942491571b1ce17ef81272356a9

132 bits matched, 16 leading. That's around 62.2 bits of classical difficulty.

Let's see if anyone can find the key.

Code:

13BSwDFachETtwunbnmNrRpdNt1Hp8cipS
Found by kTimesG; x = f(y**2)
IPEdHGDZwGFpxiwzmMll6wEDFWtlFCEHnKu7e53EEhwGZdtM3sPDdZWmy0saVsdu8Kqu5fERrtkvlcUZ59u2WSs

What are you doing ? And what kind of bias ? 🤔