Post
Topic
Board Bitcoin Discussion
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
by
Virtuose
on 04/07/2025, 00:42:53 UTC
Buddy, here’s the A + B you keep dodging:

A. Toy range vs. real world
Your demo space = 2¹⁷ ≈ 131 k keys.
Hit rate for a 3-hex prefix there: (131 072 / 4096) ≈ 32 possible matches — easy pickings.

B. Actual Bitcoin key space
Size = 2²⁵⁶ ≈ 1.16 × 10⁷⁷.
Same prefix filter: 2²⁵⁶ / 4096 = 2²⁴⁴ ≈ 2.9 × 10⁷³ candidates.

At 1 trillion keys/sec (fantasy hardware) you’d still need ≈ 9 × 10⁶¹ years to exhaust those 2.9 × 10⁷³ keys. Your “67% success” collapses to 0 % in any universe that isn’t a 131 k fishbowl.

Uniformity doesn’t save you; it condemns you: every prefix is evenly packed with an astronomical number of keys. All you did was shrink the pond, hook a fish, then brag you’ve solved deep-sea fishing.

Keep moving those goalposts, mathematics will keep flattening them.

First, you don't need to quote the entire content, just what you're going to answer. This way, you avoid post-to-post content overload; no one is interested in reading the same thing every other post.

Second, as I told you, the search space doesn't matter here. It's statistically the same. If my script uses a low bit rate and wins 63% of the time on average, the same thing will happen using 10 prefixes and blocks of 1099511627776, or whatever size you come up with, as long as the idea is respected.

Third, you're confusing collision frequency with success probability.

Dude, you keep proving you don’t grasp basic probability.

Prefix math: 101

A 3-hex prefix is a 12-bit filter → 1 / 4096 hit-rate no matter the keyspace size.

Extend to a 10-hex prefix? That’s 40 bits: success odds = 1 / 2⁴⁰ ≈ 1 in a trillion.

Now look at your “63% win” claim:

You preset the target inside every block you scan, so there’s guaranteed to be at least one key that matches the full h160. Of course you “find” it most of the time, your script is playing hide-and-seek in a broom closet.

Scale that closet up to the real 2²⁵⁶-key universe and the expected number of matches per block collapses from “one or two” to 0.000…1 (40+ zeros). Your success rate plummets to statistical dust.

Different block sizes, ten prefixes, a bajillion prefixes doesn’t matter. Uniform randomness means you still need to brute-force ≈2²⁴⁴ keys for a single 3-digit hit on average. That’s 9 × 10⁶¹ centuries at 1 T keys/sec.

Stop moving the goalposts; start learning the rules. Your “idea” violates arithmetic, not just cryptography.