Bitcoin puzzle transaction ~32 BTC prize to who solves it

[mahmood1356]

In theory, everything is simple, yes and no. You just need to create your own random generator, with all these exceptions, then no additional verification is needed. The generator is not needed numeric, but directly in hex

The random data is binary anyway. Why don't you use octal instead of hex? Or binary directly?

This is a very relevant question, because private key data and hashes are inherently binary. However, the choice of how to represent them in projects like a rainbow table is completely intentional
While everything is ultimately binary, hexadecimal provides a balance of compactness, readability, analyzability, and compatibility with cryptographic tools, making it a logical and standard choice for such projects.

[nochkin]

While everything is ultimately binary, hexadecimal provides a balance of compactness, readability, analyzability, and compatibility with cryptographic tools, making it a logical and standard choice for such projects.

This is my point exactly. It's just for human readability and has nothing to do with repeating characters/digits when properly randomized.

[teguh54321]

My question is whether, using the method and specifications that I'll describe, it's possible to write Python code to apply the given filters and perform the search?

400000000000000000  to  7FFFFFFFFFFFFFFFFF
(corresponding to decimal values from 1180591620717411303424 to 2361183241434822606847).

Total number of keys in this range is:
1180591620717411303424

Filtering Criteria:
We filter out all keys whose first four hexadecimal characters (prefixes) follow the pattern:

The first character is one of 4, 5, 6, or 7,

Followed by three identical hexadecimal digits (0-9, A-F).

Thus, for each leading digit, the filtered prefixes are:

For 4:
4AAA, 4BBB, 4CCC, 4DDD, 4EEE, 4FFF, 4000, 4111, 4222, 4333, 4444, 4555, 4666, 4777, 4888, 4999

For 5:
5AAA, 5BBB, 5CCC, 5DDD, 5EEE, 5FFF, 5000, 5111, 5222, 5333, 5444, 5555, 5666, 5777, 5888, 5999

For 6:
6AAA, 6BBB, 6CCC, 6DDD, 6EEE, 6FFF, 6000, 6111, 6222, 6333, 6444, 6555, 6666, 6777, 6888, 6999

For 7:
7AAA, 7BBB, 7CCC, 7DDD, 7EEE, 7FFF, 7000, 7111, 7222, 7333, 7444, 7555, 7666, 7777, 7888, 7999

(Each group includes 16 prefixes corresponding to all possible repeated digits 0-9 and A-F.)

Calculations:
Number of filtered prefixes:
4 (leading digits) × 16 (repeated-digit prefixes) = 64

Number of keys per prefix:
Total keys ÷ 2^16 =
1180591620717411303424 ÷ 65536 = 18015511019655507

Total keys filtered:
64 × 18015511019655507 = 1152976705257952448

Percentage of keys filtered:
(1152976705257952448 ÷ 1180591620717411303424) × 100 ≈ 97.7%

Conclusion:
Applying this filtering criterion removes approximately 97.7% of all private keys within the specified range.

Or maybe I made a mistake in my calculations? Please guide me.
 Thank you.

Yeah i also think bout this.

Mybe also add prefix jump .  But risk missing the target

[btc11235]

Are we really all out of ideas? How about this: Any thoughts on the old wallets that just woke up today (or yesterday)? Lots of BTC suddenly moving out of old wallets... Reminds me of some puzzles we're all trying to solve... And I'll take any crazy, long-shot speculation/discussion about how those wallets may have been hacked...

NOT Satoshi's wallets... I'm talking about Satoshi-era wallets (meaning from back in the day). Most of those coins got consolidated from Legacy addresses to Bech32 addresses. Not sent to exchanges. I guess it’s a big deal to move your crypto to more secure wallets? Bunch of panic-sellers and FUD-spreaders overreacting online.

Oh, is that all? Poo

Are you still working on solving any of the remaining puzzles, or have you permanently gone fishing?

[mahmood1356]

Why not reach these addresses yet?
 Each of these is in completely different points, as I may think that there is no!

 1PWo3JeB9jrGwfHDNpdGK54CRas7BJwzGg
1PWo3JeB9jrGwfHDNpdGK54CRas8JAZddJ
1PWo3JeB9jrGwfHDNpdGK54CRas7sVHpYM

[teguh54321]

Why not reach these addresses yet?
 Each of these is in completely different points, as I may think that there is no!

 1PWo3JeB9jrGwfHDNpdGK54CRas7BJwzGg
1PWo3JeB9jrGwfHDNpdGK54CRas8JAZddJ
1PWo3JeB9jrGwfHDNpdGK54CRas7sVHpYM

Wow can i get the hex ? 🙏. This might help for prefix jump. Does it far away ?

[MrGPBit]

Why not reach these addresses yet?
 Each of these is in completely different points, as I may think that there is no!

 1PWo3JeB9jrGwfHDNpdGK54CRas7BJwzGg
1PWo3JeB9jrGwfHDNpdGK54CRas8JAZddJ
1PWo3JeB9jrGwfHDNpdGK54CRas7sVHpYM

1PWo3JeB9jrGwfHDNpdGK54CRas7o1Quvw
1PWo3JeB9jrGwfHDNpdGK54CRas7SKdbnS
1PWo3JeB9jrGwfHDNpdGK54CRas7JiafEz
1PWo3JeB9jrGwfHDNpdGK54CRas79PsfyU

[teguh54321]

Why not reach these addresses yet?
 Each of these is in completely different points, as I may think that there is no!

 1PWo3JeB9jrGwfHDNpdGK54CRas7BJwzGg
1PWo3JeB9jrGwfHDNpdGK54CRas8JAZddJ
1PWo3JeB9jrGwfHDNpdGK54CRas7sVHpYM

1PWo3JeB9jrGwfHDNpdGK54CRas7o1Quvw
1PWo3JeB9jrGwfHDNpdGK54CRas7SKdbnS
1PWo3JeB9jrGwfHDNpdGK54CRas7JiafEz
1PWo3JeB9jrGwfHDNpdGK54CRas79PsfyU

Please share the hex 🙏🙏.  By sharing mybe when someone solve it , they will give you tips 😅. If i solve it i would haha

[teguh54321]

Why not reach these addresses yet?
 Each of these is in completely different points, as I may think that there is no!

 1PWo3JeB9jrGwfHDNpdGK54CRas7BJwzGg
1PWo3JeB9jrGwfHDNpdGK54CRas8JAZddJ
1PWo3JeB9jrGwfHDNpdGK54CRas7sVHpYM

1PWo3JeB9jrGwfHDNpdGK54CRas7o1Quvw
1PWo3JeB9jrGwfHDNpdGK54CRas7SKdbnS
1PWo3JeB9jrGwfHDNpdGK54CRas7JiafEz
1PWo3JeB9jrGwfHDNpdGK54CRas79PsfyU

1PWo3JeB9jrGwfHDNpdGK54CRas79PsfyU

1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU

Wow seems near ?

[dulala2028]

Why not reach these addresses yet?
 Each of these is in completely different points, as I may think that there is no!

 1PWo3JeB9jrGwfHDNpdGK54CRas7BJwzGg
1PWo3JeB9jrGwfHDNpdGK54CRas8JAZddJ
1PWo3JeB9jrGwfHDNpdGK54CRas7sVHpYM

1PWo3JeB9jrGwfHDNpdGK54CRas7o1Quvw
1PWo3JeB9jrGwfHDNpdGK54CRas7SKdbnS
1PWo3JeB9jrGwfHDNpdGK54CRas7JiafEz
1PWo3JeB9jrGwfHDNpdGK54CRas79PsfyU

1PWo3JeB9jrGwfHDNpdGK54CRas79PsfyU

1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU

Wow seems near ?

       


This is definitely fake, it seems that the puzzle creator is going to transfer the BTC balance!

[teguh54321]

How to search prefix but not the first digit ?
Any idea ? Or program ?

Lets say i want prefix but from the fifth digit

Like  example
****3JeB9jrGw

So not  from front

The * can be any....

Or any feature in here that can do that ??
https://github.com/FixedPaul/VanitySearch-Bitcrack

[iceland2k14]

My question is whether, using the method and specifications that I'll describe, it's possible to write Python code to apply the given filters and perform the search?

400000000000000000  to  7FFFFFFFFFFFFFFFFF
........
Filtering Criteria:
We filter out all keys whose first four hexadecimal characters (prefixes) follow the pattern:

The first character is one of 4, 5, 6, or 7,
Followed by three identical hexadecimal digits (0-9, A-F).

Conclusion:
Applying this filtering criterion removes approximately 97.7% of all private keys within the specified range.

Yes you have done a big Mistake.
For each 3 hex character after first digit (4,5,6,7) there are total 4096 possibilities. Out of which you are removing the identical chars (total 16). That leaves 4080 still valid keys after each starting digit.  4xxx, 5xxx, 6xxx, 7xxx

That means you have to still solve 99.61 % of the remaining keyspace. Congratulations to Reality.

[Virtuose]

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.

[mahmood1356]

How to search prefix but not the first digit ?
Any idea ? Or program ?

Lets say i want prefix but from the fifth digit

Like  example
****3JeB9jrGw

So not  from front

The * can be any....

Or any feature in here that can do that ??
https://github.com/FixedPaul/VanitySearch-Bitcrack

def search_prefix_from_position(string, position):
    prefix = string[position - 1:]
    return prefix

# Example
string = "****3JeB9jrGw"
position = 5
prefix = search_prefix_from_position(string, position)
print(f"Prefix from position {position}: {prefix}")

[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