Bitcoin puzzle transaction ~32 BTC prize to who solves it

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

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

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.

Your analogy with dice tells me you still don't understand prefix searching. No, that's not what I'm saying. If you focused on understanding more and hating less, you would easily understand what the probabilistic prefix search method is based on. The fact that a six appears on the fifth roll doesn't mean that another 6 is less likely on the sixth; they are independent events. But it is true that if they tell you to roll a die 6 times, and the second time you got a 6, it's normal for you to bet that there won't be another 6 in the next 4 events. Although it could happen, statistically it doesn't change the probability of 1/6.

Now, when I say it's broken, if it becomes frequent, it would mean that for every 6 rolls you get two 6s. If these occurrences become frequent, it could be said that the die is rigged or defective.

And in the case of prefixes, the same thing happens. If the probability 2/4096 becomes common, it would mean the hash is broken.

I don't think their hatred will stop them from seeing what the script already irrefutably verifies.

Do you get it now?

[Virtuose]

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.

Your analogy with dice tells me you still don't understand prefix searching. No, that's not what I'm saying. If you focused on understanding more and hating less, you would easily understand what the probabilistic prefix search method is based on. The fact that a six appears on the fifth roll doesn't mean that another 6 is less likely on the sixth; they are independent events. But it is true that if they tell you to roll a die 6 times, and the second time you got a 6, it's normal for you to bet that there won't be another 6 in the next 4 events. Although it could happen, statistically it doesn't change the probability of 1/6.

Now, when I say it's broken, if it becomes frequent, it would mean that for every 6 rolls you get two 6s. If these occurrences become frequent, it could be said that the die is rigged or defective.

And in the case of prefixes, the same thing happens. If the probability 2/4096 becomes common, it would mean the hash is broken.

I don't think their hatred will stop them from seeing what the script already irrefutably verifies.

Do you get it now?

Dude, every dev watching this thread is cracking up.

A 3-hex prefix is a 12-bit filter, 1 hit per 4 096 keys. Your script “wins” only because you fence the target inside a toy range of 2¹⁷ keys. In that puddle you expect 32 prefix matches, so stumbling on the right one 60 % of the time is no feat at all.

Scale to the real 2²⁵⁶-key ocean and you face 2²⁴⁴ such blocks; even with your pruning you’d still churn through ≈2²⁵⁵ hashes, basically the same work as a straight brute-force. The supposed speed-up vanishes.

If prefixes really repeated 2 times out of 3, SHA-256 would already be toast. They don’t, so your “probabilistic” shortcut is just a dressed-up linear scan in an aquarium.

Long story short: the math buries your claim, and your script is a party trick nothing more. You’re so ridiculous at this point, blinded by your own ignorance that it’s hard to tell whether you’re doing it on purpose or you’re just trolling for attention. No one’s fooled, so just move along.

[mahmood1356]

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

[MrGPBit]

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

[mahmood1356]

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

[MrGPBit]

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

Wandering Philosopher made the prefix list public when he stopped searching