Bitcoin puzzle transaction ~32 BTC prize to who solves it

[nochkin]

Imagine how much more quickly these keys would be solved if we teamed up resources/knowledge instead of constantly arguing about petty bs. It's embarrassing.

At least, you can join a pool to team up using brute-force.

AAAA BBBB or AAA BBB or ACACAC  etc... imagine how much skip 😅

Chances that AAAAA is ok to skip are the same as skipping 1E53A or 9A1BE.

[nightdreams]

Imagine how much more quickly these keys would be solved if we teamed up resources/knowledge instead of constantly arguing about petty bs. It's embarrassing.

Hehe , everyone wants to be a solo winner 🤪🤪🤪...

My effort now just make an efficient brute with tight and loose rule in skip and jump.  But the risk of tight rule is missing the target address. Example skipping all private key contain AAAA BBBB or AAA BBB or ACACAC  etc... imagine how much skip 😅

Im aiming for 5-10x faster brute  so 71 roi still good.  But the risk with my method is that I might miss the target if it contains the 'thing' I'm skipping 🙃

Still, every number also have same probability. 
Just like buying lottery, if you don't treat this "0000" as special number, they are still same probability as 1234, 2136....

[ericb148]

basically we should try a different approach. I am starting with the idea of ​​converting the private keys to binary, as per the author's comment. It is easy to see that the keys all start with 101,100,110,111 and the substrings inside are 00, 11, 000, 111, 0000,11111,... we can reduce the search space quite a bit here, we can use more markov chains to generate high probability strings first. Generating keys and applying keyhunt will help speed things up a lot.

[kTimesG]

basically we should try a different approach. I am starting with the idea of ​​converting the private keys to binary, as per the author's comment. It is easy to see that the keys all start with 101,100,110,111 and the substrings inside are 00, 11, 000, 111, 0000,11111,... we can reduce the search space quite a bit here, we can use more markov chains to generate high probability strings first. Generating keys and applying keyhunt will help speed things up a lot.

All numbers are binary, there's nothing to convert there, since that's what they already are. And every bit at every position has a 50% chance of being either 0 or 1, because all keys have an equal chance of success, and there are 2**70 keys times 70 bits each, and they all go from 0...0 to 1...1. Out of all of them, half of the bits are 0, and half are 1.

There is no bias, except maybe for human eyes, which has no impact anyway. Applying data compression to strings of bits doesn't make some keys or bit substrings more or less likely, since this would mean that somehow the universe gives more priority to some combinations, instead of each of them having equal chances.

[fecell]

And every bit at every position has a 50% chance of being either 0 or 1

wrong.
value 101010100101010100101010100101010100101010100....101010100 impossible too.
have generator by statistic for huge amount of random numbers. its a very nice with python, but very slow for real work.
so do a CircleTraversal (up to 255 bit range) for GPU, its a best DLP solution (may be soon will publish).

[kTimesG]

And every bit at every position has a 50% chance of being either 0 or 1

wrong.
value 101010100101010100101010100101010100101010100....101010100 impossible too.
have generator by statistic for huge amount of random numbers. its a very nice with python, but very slow for real work.
so do a CircleTraversal (up to 255 bit range) for GPU, its a best DLP solution (may be soon will publish).

Are you saying that the private key 101010100101010100101010100101010100101010100....101010100 does not exist as one of the 2**70 equally likely options? Well, that's new.

Any decent random generator will use entropy that guarantees that you get 0 and 1 with equal chances, otherwise it's broken.

[teguh54321]

And every bit at every position has a 50% chance of being either 0 or 1

wrong.
value 101010100101010100101010100101010100101010100....101010100 impossible too.
have generator by statistic for huge amount of random numbers. its a very nice with python, but very slow for real work.
so do a CircleTraversal (up to 255 bit range) for GPU, its a best DLP solution (may be soon will publish).

Are you saying that the private key 101010100101010100101010100101010100101010100....101010100 does not exist as one of the 2**70 equally likely options? Well, that's new.

Any decent random generator will use entropy that guarantees that you get 0 and 1 with equal chances, otherwise it's broken.

Hmm so might be some kind of anomaly 🤔🤔🤔

[Fahankhan]

But why is it that Keyhunt CPU is not available yet? at least that could be a starting point..

[mahmood1356]

Prefixes [1PWo3JeB9j] identical to number800 If there is, does it have an impact on the target key search process?

[iceland2k14]

As the search space is getting bigger and bigger each time we are moving up in the puzzle, there are more people inclined towards every kind of skip search, they can think of. Unless someone hit one of the puzzle using those skipping technique there will be always both crtisizm and appreciation. Deal with it.

[mcdouglasx]

Prefixes [1PWo3JeB9j] identical to number800 If there is, does it have an impact on the target key search process?

The math is simple: for example, in a 4096-bit search space, an h160 prefix is ​​found on average once. If this were frequent (2 out of 3 prefixes in 4096 bits), the hash function would be broken. That's why this is a good guide for probabilistic searches. Anyone who says otherwise is wrong.

It's not worth relying on addresses; you're just wasting resources.

Here's a script that shows you, without much fanfare, that prefix searching isn't as useless as some claim. Run it yourself and draw your own conclusions:

The Iceland module is required.

https://github.com/iceland2k14/secp256k1 The Iceland files must be in the same location where you saved this script. Some operating systems require Visual Studio Redistributables to be installed for it to work.

You can adjust the number of tests by setting total_runs = 100.

Code:

import random
import secp256k1 as ice
import concurrent.futures

# Configuration
START = 131071
END = 262143
BLOCK_SIZE = 4096
MIN_PREFIX = 3
MAX_WORKERS = 4
TOTAL_RUNS = 100

def generate_blocks(start, end, block_size):
    """
    Split the keyspace [start..end] into blocks of size block_size,
    then shuffle the block list for randomized dispatch.
    """
    total_keys = end - start + 1
    num_blocks = (total_keys + block_size - 1) // block_size
    blocks = [
        (start + i * block_size,
         min(start + (i + 1) * block_size - 1, end))
        for i in range(num_blocks)
    ]
    random.shuffle(blocks)
    return blocks

def scan_block(b0, b1, target):
    """
    Scan keys in [b0..b1] looking for target.
    Prune the block only if both conditions happen in order:
      1) A false positive on MIN_PREFIX hex chars
      2) Later, a match on the first MIN_PREFIX-1 hex chars
    """
    full_pref = target[:MIN_PREFIX]
    half_pref = target[:MIN_PREFIX - 1]

    for key in range(b0, b1 + 1):
        addr = ice.privatekey_to_h160(0, 1, key).hex()
        if addr == target:
            return True, key
        if addr.startswith(full_pref) and addr != target:
            next_key = key + 1
            break
    else:
        return False, None

    for key in range(next_key, b1 + 1):
        addr = ice.privatekey_to_h160(0, 1, key).hex()
        if addr == target:
            return True, key
        if addr.startswith(half_pref):
            break

    return False, None

def worker(block_chunk, target):
    """
    Scan each block in block_chunk sequentially.
    Return the key if found, else None.
    """
    for b0, b1 in block_chunk:
        found, key = scan_block(b0, b1, target)
        if found:
            return key
    return None

def parallel_scan(blocks, target):
    """
    Distribute blocks round-robin across MAX_WORKERS processes.
    Returns the discovered key or None.
    """
    chunks = [blocks[i::MAX_WORKERS] for i in range(MAX_WORKERS)]
    with concurrent.futures.ProcessPoolExecutor(max_workers=MAX_WORKERS) as executor:
        futures = [executor.submit(worker, chunk, target) for chunk in chunks]
        for future in concurrent.futures.as_completed(futures):
            key = future.result()
            if key is not None:
                for f in futures:
                    f.cancel()
                return key
    return None

if __name__ == "__main__":
    found_count = 0
    not_found_count = 0

    for run in range(1, TOTAL_RUNS + 1):
        target_key = random.randint(START, END)
        target = ice.privatekey_to_h160(0, 1, target_key).hex()

        blocks = generate_blocks(START, END, BLOCK_SIZE)
        key = parallel_scan(blocks, target)

        if key is not None:
            found_count += 1
        else:
            not_found_count += 1

    print(f"\nOf {TOTAL_RUNS} runs, found: {found_count}, not found: {not_found_count}")

R: Of 100 runs, found: 67, not found: 33

If you reduce the block size by 25% BLOCK_SIZE = 3072 your success percentage will obviously increase, but it will involve covering more space to increase your success rate.

r:Of 100 runs, found: 78, not found: 22


Therefore, searching for prefixes is the best method as long as you are not trying to scan the entire range (just try your luck).

Disclaimer for the know-it-alls: yes, the code is partially done with AI but it is completely correct.

[kTimesG]

The math is simple: for example, in a 4096-bit search space, an h160 prefix is ​​found on average once. If this were frequent (2 out of 3 prefixes in 4096 bits), the hash function would be broken. That's why this is a good guide for probabilistic searches. Anyone who says otherwise is wrong.

No, what's wrong is that you misinterpret the math and make some false statements. You are contradicting the very basis of actual theory of probabilities.

No, the hash function ain't broke if you find some prefix zero times, once, twice, or a hundred times (and it will happen if you keep trying, or else reality is broken, not the hash).

The often edge cases will eventually be counter-weighted by their opposite encounters (ranges with zero results).

You should straight up go to Princeton and give some lectures about this before they call the police.

[mcdouglasx]

The math is simple: for example, in a 4096-bit search space, an h160 prefix is ​​found on average once. If this were frequent (2 out of 3 prefixes in 4096 bits), the hash function would be broken. That's why this is a good guide for probabilistic searches. Anyone who says otherwise is wrong.

No, what's wrong is that you misinterpret the math and make some false statements. You are contradicting the very basis of actual theory of probabilities.

No, the hash function ain't broke if you find some prefix zero times, once, twice, or a hundred times (and it will happen if you keep trying, or else reality is broken, not the hash).

The often edge cases will eventually be counter-weighted by their opposite encounters (ranges with zero results).

You should straight up go to Princeton and give some lectures about this before they call the police.

Finding more than 1 (a prefix of length 3) in 4096 is rare, and omitting the target is even rarer. The length of the prefix doesn't matter as long as the block matches what's expected.
Nor do you try as much as you try, the probability will remain ≈ the same.
If finding more identical prefixes within 4096 were no longer so rare, the hashes would be broken.

You betray your intelligence in order to obscure ideas you don't share.

[kTimesG]

You should straight up go to Princeton and give some lectures about this before they call the police.

Finding more than 1 (a prefix of length 3) in 4096 is rare, and omitting the target is even rarer. The length of the prefix doesn't matter as long as the block matches what's expected.
Nor do you try as much as you try, the probability will remain ≈ the same.
If finding more identical prefixes within 4096 were no longer so rare, the hashes would be broken.

I will again state that you don't really understand how an uniform distribution works. You're simplifying to a yes/no gambling, forgetting completely about the basics of it.

If finding more prefixes in some portion means the hash's broken, man, please don't make me provide actual examples about how wrong you are.

When you skip some rest of "block" as you call it, you simply move off the chances of finding (or not finding) another prefix, into the next block. Basically, a futile operation to perform, because it goes the other way around too: when you fail to find some prefix in the next "block" or whatever, it might simply mean (at an average level) that it was found in the skipped portion. Or any other portion, anywhere, to be honest. Because, for the 9000th time (for you): it's an uniform distribution, all keys are as likely as others, and all ranges are as likely as any other ranges.

So you're simply selling some illusion of some sort of benefit, but it does not exist, neither in theory, nor in practice. It would be great if it would, though.

[Virtuose]

Prefixes [1PWo3JeB9j] identical to number800 If there is, does it have an impact on the target key search process?

The math is simple: for example, in a 4096-bit search space, an h160 prefix is ​​found on average once. If this were frequent (2 out of 3 prefixes in 4096 bits), the hash function would be broken. That's why this is a good guide for probabilistic searches. Anyone who says otherwise is wrong.

It's not worth relying on addresses; you're just wasting resources.

Here's a script that shows you, without much fanfare, that prefix searching isn't as useless as some claim. Run it yourself and draw your own conclusions:

The Iceland module is required.

https://github.com/iceland2k14/secp256k1 The Iceland files must be in the same location where you saved this script. Some operating systems require Visual Studio Redistributables to be installed for it to work.

You can adjust the number of tests by setting total_runs = 100.

Code:

import random
import secp256k1 as ice
import concurrent.futures

# Configuration
START = 131071
END = 262143
BLOCK_SIZE = 4096
MIN_PREFIX = 3
MAX_WORKERS = 4
TOTAL_RUNS = 100

def generate_blocks(start, end, block_size):
    """
    Split the keyspace [start..end] into blocks of size block_size,
    then shuffle the block list for randomized dispatch.
    """
    total_keys = end - start + 1
    num_blocks = (total_keys + block_size - 1) // block_size
    blocks = [
        (start + i * block_size,
         min(start + (i + 1) * block_size - 1, end))
        for i in range(num_blocks)
    ]
    random.shuffle(blocks)
    return blocks

def scan_block(b0, b1, target):
    """
    Scan keys in [b0..b1] looking for target.
    Prune the block only if both conditions happen in order:
      1) A false positive on MIN_PREFIX hex chars
      2) Later, a match on the first MIN_PREFIX-1 hex chars
    """
    full_pref = target[:MIN_PREFIX]
    half_pref = target[:MIN_PREFIX - 1]

    for key in range(b0, b1 + 1):
        addr = ice.privatekey_to_h160(0, 1, key).hex()
        if addr == target:
            return True, key
        if addr.startswith(full_pref) and addr != target:
            next_key = key + 1
            break
    else:
        return False, None

    for key in range(next_key, b1 + 1):
        addr = ice.privatekey_to_h160(0, 1, key).hex()
        if addr == target:
            return True, key
        if addr.startswith(half_pref):
            break

    return False, None

def worker(block_chunk, target):
    """
    Scan each block in block_chunk sequentially.
    Return the key if found, else None.
    """
    for b0, b1 in block_chunk:
        found, key = scan_block(b0, b1, target)
        if found:
            return key
    return None

def parallel_scan(blocks, target):
    """
    Distribute blocks round-robin across MAX_WORKERS processes.
    Returns the discovered key or None.
    """
    chunks = [blocks[i::MAX_WORKERS] for i in range(MAX_WORKERS)]
    with concurrent.futures.ProcessPoolExecutor(max_workers=MAX_WORKERS) as executor:
        futures = [executor.submit(worker, chunk, target) for chunk in chunks]
        for future in concurrent.futures.as_completed(futures):
            key = future.result()
            if key is not None:
                for f in futures:
                    f.cancel()
                return key
    return None

if __name__ == "__main__":
    found_count = 0
    not_found_count = 0

    for run in range(1, TOTAL_RUNS + 1):
        target_key = random.randint(START, END)
        target = ice.privatekey_to_h160(0, 1, target_key).hex()

        blocks = generate_blocks(START, END, BLOCK_SIZE)
        key = parallel_scan(blocks, target)

        if key is not None:
            found_count += 1
        else:
            not_found_count += 1

    print(f"\nOf {TOTAL_RUNS} runs, found: {found_count}, not found: {not_found_count}")

R: Of 100 runs, found: 67, not found: 33

If you reduce the block size by 25% BLOCK_SIZE = 3072 your success percentage will obviously increase, but it will involve covering more space to increase your success rate.

r:Of 100 runs, found: 78, not found: 22


Therefore, searching for prefixes is the best method as long as you are not trying to scan the entire range (just try your luck).

Disclaimer for the know-it-alls: yes, the code is partially done with AI but it is completely correct.

But your simple math forgets math 

1 An h160 is 40 hex digits; matching just 3 gives you a 1 in 4096 filter.
2 Your script already knows the target key sits in a tiny 131 k value window: rigged lotto, congrats.
3 A 67% hit rate when the fish is trapped in the bowl only shows your heuristic is shaky; at the real scale (2^256 keys) that boost rounds to 0.000%.
4 If 2/3 of prefixes really repeated, SHA-256 would be broken, so yet you use it to “prove” it’s secure. That’s some top-tier circular logic.

Scanning prefixes in a kiddie pool proves nothing except your confusion between a demo and Python sleight of hand.

[mcdouglasx]

You should straight up go to Princeton and give some lectures about this before they call the police.

Finding more than 1 (a prefix of length 3) in 4096 is rare, and omitting the target is even rarer. The length of the prefix doesn't matter as long as the block matches what's expected.
Nor do you try as much as you try, the probability will remain ≈ the same.
If finding more identical prefixes within 4096 were no longer so rare, the hashes would be broken.

I will again state that you don't really understand how an uniform distribution works. You're simplifying to a yes/no gambling, forgetting completely about the basics of it.

If finding more prefixes in some portion means the hash's broken, man, please don't make me provide actual examples about how wrong you are.

When you skip some rest of "block" as you call it, you simply move off the chances of finding (or not finding) another prefix, into the next block. Basically, a futile operation to perform, because it goes the other way around too: when you fail to find some prefix in the next "block" or whatever, it might simply mean (at an average level) that it was found in the skipped portion. Or any other portion, anywhere, to be honest. Because, for the 9000th time (for you): it's an uniform distribution, all keys are as likely as others, and all ranges are as likely as any other ranges.

So you're simply selling some illusion of some sort of benefit, but it does not exist, neither in theory, nor in practice. It would be great if it would, though.

The advantage of prefixes is that it's not common to find multiple prefixes of a hash in a space x where their probability is 1/x. This math isn't going to change even if you cry. For that single, indisputable mathematical reason, searching with prefixes is the most convenient, since they're based on REAL probabilities, the properties of a uniform distribution.

1st grade fact: A uniform distribution only means that the target is equally distributed, not that all stopping criteria perform equally.

LOL, each stopping criterion changes the probability of success within the block, even with a uniform distribution.

Pruning by 3 hex prefix: success ≈ 63.2%

Stopping at a random point: success ≈ 50%

Finding ≥ 2 prefix collisions in 4096 keys is very rare; if it were frequent, the hash function would be compromised (this doesn't mean there can't be cases where it happens, but the point is that for what the prefix lookup requires, it works).

Missing the target due to premature collision occurs in the remaining ~36.8%, just as the script predicts. I don't understand why you flatly deny this fact.

Instead of continuing to cry or hesitate, accept it.

I'm 100% sure you understand what I mean; your time, like the modern Digaran, is simply imprinted on you.

snip

Come on, man, you're taking all the fun out of mixing so much nonsense into a single post.

The 3-hex filter is 1/4096 in any space. It doesn't matter if the hash has 40 digits, the probability of matching the first 3 is always the same.

Limiting the range doesn't "fix" the math: the uniformity remains within that subspace, and the formula applies the same.

Going from 4096 to 2**256 only changes the scale. The exponential form is the same; the relative result remains the same.

kgtimes, you won't respond to this guy's statements, or you'll apply the "the enemies of my enemies are my friends" rule .

[Virtuose]

You should straight up go to Princeton and give some lectures about this before they call the police.

Finding more than 1 (a prefix of length 3) in 4096 is rare, and omitting the target is even rarer. The length of the prefix doesn't matter as long as the block matches what's expected.
Nor do you try as much as you try, the probability will remain ≈ the same.
If finding more identical prefixes within 4096 were no longer so rare, the hashes would be broken.

I will again state that you don't really understand how an uniform distribution works. You're simplifying to a yes/no gambling, forgetting completely about the basics of it.

If finding more prefixes in some portion means the hash's broken, man, please don't make me provide actual examples about how wrong you are.

When you skip some rest of "block" as you call it, you simply move off the chances of finding (or not finding) another prefix, into the next block. Basically, a futile operation to perform, because it goes the other way around too: when you fail to find some prefix in the next "block" or whatever, it might simply mean (at an average level) that it was found in the skipped portion. Or any other portion, anywhere, to be honest. Because, for the 9000th time (for you): it's an uniform distribution, all keys are as likely as others, and all ranges are as likely as any other ranges.

So you're simply selling some illusion of some sort of benefit, but it does not exist, neither in theory, nor in practice. It would be great if it would, though.

The advantage of prefixes is that it's not common to find multiple prefixes of a hash in a space x where their probability is 1/x. This math isn't going to change even if you cry. For that single, indisputable mathematical reason, searching with prefixes is the most convenient, since they're based on REAL probabilities, the properties of a uniform distribution.

1st grade fact: A uniform distribution only means that the target is equally distributed, not that all stopping criteria perform equally.

LOL, each stopping criterion changes the probability of success within the block, even with a uniform distribution.

Pruning by 3 hex prefix: success ≈ 63.2%

Stopping at a random point: success ≈ 50%

Finding ≥ 2 prefix collisions in 4096 keys is very rare; if it were frequent, the hash function would be compromised (this doesn't mean there can't be cases where it happens, but the point is that for what the prefix lookup requires, it works).

Missing the target due to premature collision occurs in the remaining ~36.8%, just as the script predicts. I don't understand why you flatly deny this fact.

Instead of continuing to cry or hesitate, accept it.

I'm 100% sure you understand what I mean; your time, like the modern Digaran, is simply imprinted on you.

snip

Come on, man, you're taking all the fun out of mixing so much nonsense into a single post.

The 3-hex filter is 1/4096 in any space. It doesn't matter if the hash has 40 digits, the probability of matching the first 3 is always the same.

Limiting the range doesn't "fix" the math: the uniformity remains within that subspace, and the formula applies the same.

Going from 4096 to 2**256 only changes the scale. The exponential form is the same; the relative result remains the same.

kgtimes, you won't respond to this guy's statements, or you'll apply the "the enemies of my enemies are my friends" rule .

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.

[mcdouglasx]

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.

[fixedpaul]

The math is simple: for example, in a 4096-bit search space, an h160 prefix is ​​found on average once. If this were frequent (2 out of 3 prefixes in 4096 bits), the hash function would be broken. That's why this is a good guide for probabilistic searches. Anyone who says otherwise is wrong.

The math is simple: for example, in a 6 dice rolls, a "six" comes up on average once. If this were frequent (2 out of 3 times in 6 rolls), the die would be broken. That's why this is a good guide for probabilistic searches. Anyone who says otherwise is wrong.

So, if I'm rolling one of my 6 dice one at a time and a "six" shows up, say, on the fifth roll, then the last roll has a lower chance of being a "six", right? Otherwise the die is rigged. I guess we need to rewrite the definition of uniform distribution in math textbooks.

[Virtuose]

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.