BITCOIN PUZZLE: THE PREFIX DILEMMA - A follow up

[nomachine]

Works on Small Puzzles

The keyspace is actually easy to walk through
Prefix hits pop off pretty often
You hit PREFIX_UPGRADE_HITS = 3 real quick
Prefix length keeps leveling up
Adaptive jumping low-key smart

lol you can crack small puzzles any way you want, even on a potato PC 

[kTimesG]

Do we really need someone to code this out, to end this stupid non-sense once and for all?

- randomize (shuffle) the range keys, let's call this sequence S

then apply to S whatever idiotic algorithm you can think of that finds prefixes and skips keys and whatever.

You'll get the same results, I am willing to bet an arm and a leg that you will get the exact same results and the same "efficiency", which can only prove that H160 is a uniform distribution and the idea of location biases, skips, and whatever is simply cognitive bias, which also goes by the name of Gambler's Fallacy.

[nomachine]

If the hash is truly random, then the order you search keys doesn’t matter.

Backwards?
Every third key?
Start at f6f5431d?
Zig-zag?
Shuffle first and then act like you’re being clever?

Makes zero difference for me.

You can shuffle the whole keyspace, scan it in reverse, hop around, chase prefixes, invent “smart jumps”
at the end of the day, it’s all just personal preference and a way to stay entertained while you burn CPU cycles for the rest of your life.

[Akito S. M. Hosana]

it’s all just personal preference and a way to stay entertained while you burn CPU cycles for the rest of your life.

This thing’s straight-up impossible, man.
I swear these puzzles only exist to mess with people.
Feels like fishing in the middle of the ocean with a busted rod, no bait, and someone’s in your ear like,
“Nah bro, trust me, the fish is right there.”   

[mcdouglasx]

If the hash is truly random, then the order you search keys doesn’t matter.

Backwards?
Every third key?
Start at f6f5431d?
Zig-zag?
Shuffle first and then act like you’re being clever?

Makes zero difference for me.

You can shuffle the whole keyspace, scan it in reverse, hop around, chase prefixes, invent “smart jumps”
at the end of the day, it’s all just personal preference and a way to stay entertained while you burn CPU cycles for the rest of your life.

You should read the thread and try the codes; it's not that we're invalidating the cryptography, we're simply looking for something better. The numbers don't lie

[kTimesG]

If the hash is truly random, then the order you search keys doesn’t matter.

Backwards?
Every third key?
Start at f6f5431d?
Zig-zag?
Shuffle first and then act like you’re being clever?

Makes zero difference for me.

You can shuffle the whole keyspace, scan it in reverse, hop around, chase prefixes, invent “smart jumps”
at the end of the day, it’s all just personal preference and a way to stay entertained while you burn CPU cycles for the rest of your life.

You should read the thread and try the codes; it's not that we're invalidating the cryptography, we're simply looking for something better. The numbers don't lie

The only thing all the numbers showed so far is that there is zero advantage whatsoever. Otherwise, Bitcoin would have dropped to 0$

If you think there is even the slightest 0.00000000000000000000001% "bias": nope, there isn't any. All your numbers were spot on to what one expects, and there is zero efficiency gain, but actually efficiency loss. To understand this, one must be able to use a brain though.

You're only BS-ing yourself. It takes exactly 3 additional lines of code to shuffle the indexing of the generation of hashes in all of your superb AI-generated scripts, but my fear is that once you do that and realize that everything works just as "efficient" as anything else you had before, we'll only end up with "oh, but you forgot about the location bias of the location indices of the private keys of the sequence of indices of the locations of the entropy .... "..... W T F

[mcdouglasx]

If the hash is truly random, then the order you search keys doesn’t matter.

Backwards?
Every third key?
Start at f6f5431d?
Zig-zag?
Shuffle first and then act like you’re being clever?

Makes zero difference for me.

You can shuffle the whole keyspace, scan it in reverse, hop around, chase prefixes, invent “smart jumps”
at the end of the day, it’s all just personal preference and a way to stay entertained while you burn CPU cycles for the rest of your life.

You should read the thread and try the codes; it's not that we're invalidating the cryptography, we're simply looking for something better. The numbers don't lie

The only thing all the numbers showed so far is that there is zero advantage whatsoever. Otherwise, Bitcoin would have dropped to 0$

If you think there is even the slightest 0.00000000000000000000001% "bias": nope, there isn't any. All your numbers were spot on to what one expects, and there is zero efficiency gain, but actually efficiency loss. To understand this, one must be able to use a brain though.

You're only BS-ing yourself. It takes exactly 3 additional lines of code to shuffle the indexing of the generation of hashes in all of your superb AI-generated scripts, but my fear is that once you do that and realize that everything works just as "efficient" as anything else you had before, we'll only end up with "oh, but you forgot about the location bias of the location indices of the private keys of the sequence of indices of the locations of the entropy .... "..... W T F

I understand your point about hash uniformity, but you're confusing 'hashing the hash' with 'optimizing the search'.

No one is saying that H160 has bias. What the data shows is that the method acts as an exclusion filter. We don't need Bitcoin to 'drop to 0' for an algorithm to be more efficient at discarding sterile areas.

If the method were irrelevant, my simulations would show a success rate proportional to the effort (46% effort = 46% success). The math confirms that prefix browsing is a superior filtering heuristic to linear brute force.

This is game over to your criticisms.

[kTimesG]

If the method were irrelevant, my simulations would show a success rate proportional to the effort (46% effort = 46% success). The math confirms that prefix browsing is a superior filtering heuristic to linear brute force.

This is game over to your criticisms.

All that your method(s) (and WP's) confirmed, is that on average, X% effort == (2X)% success, but this is by definition of the word "average" and by the definition of the mathematical structure "uniform distribution" which you refuse to accept (if you'd accept it, you wouldn't contradict it from one sentence to the next!).

Everything else is subjective interpretation. There is no "bias" anywhere, and there is no method to search "faster" or "more efficient". There is no filtering to speak of, with any method.

So, yes, the method is irrelevant. Go back and read the numbers.

I think you should stick to gambling, math and programming isn't for everyone.

The discussion is embarrassing.

[mcdouglasx]

If the method were irrelevant, my simulations would show a success rate proportional to the effort (46% effort = 46% success). The math confirms that prefix browsing is a superior filtering heuristic to linear brute force.

This is game over to your criticisms.

All that your method(s) (and WP's) confirmed, is that on average, X% effort == (2X)% success, but this is by definition of the word "average" and by the definition of the mathematical structure "uniform distribution" which you refuse to accept (if you'd accept it, you wouldn't contradict it from one sentence to the next!).

Everything else is subjective interpretation. There is no "bias" anywhere, and there is no method to search "faster" or "more efficient". There is no filtering to speak of, with any method.

So, yes, the method is irrelevant. Go back and read the numbers.

I think you should stick to gambling, math and programming isn't for everyone.

The discussion is embarrassing.

To say that achieving a 77% success rate with 46% effort is 'normal' in a uniform distribution is simply to misunderstand what a uniform distribution is. In a uniform distribution, success is linear: 46% effort = 46% success. Anything above that is, by definition, an efficiency gain.

You've gone from saying my method is inefficient to saying its higher success rate is 'normal.' This constant contradiction only demonstrates your discomfort with a practical heuristic outperforming your textbook theory.

The numbers are there for anyone who wants to use them. While you continue debating definitions, I'll continue using methods that find 77% of the targets with half the effort.

[kTimesG]

WTF is wrong with you?...

On average, the target (e.g. the success) is at 50% of the search space (e.g. when half of the maximum work was done). The search space is at 100% of itself.

77% success with 46% effort is a disaster, since you'd only need to scan 38.5% (on average), not 46%.

You think it's better, good for you, what more can I say

Note: all of this is applicable to a non-parallel search. In a full parallel search, X% search = X% success, since all work is performed in parallel (example: all keys are checked at the same time).

I already proved to you that "parallelizing" your prefix method reaches this exact same conclusion. But it's the exact same conclusion to be reached when parallelizing the sequential method. And it's also why the prefix method cannot be parallelized.

Doing combined (parallel sequential sub-searches) can only ever, at most, converge to the serial optimum, which is, again, the average of the searched space, which is, by mathematical definition of averages, at the middle of the amount of searched space.

However, the sequential method CAN be parallelized, because there is no dependency between the sub-regions to scan. With the prefix method, the dependency makes it impossible to parallelize:

Code:

FOR block IN blocks:
   FOR key IN block:   
       IF someCondition:
           GOTO other block

Should we ask Knuth if this can be run in parallel? It's common knowledge for any CS student, no matter how many times you call it an "engineering challenge", lol.

Tautologies and truisms are not breaking discoveries.

[mcdouglasx]

snip

Confusing expected value N/2 with the cumulative probability of success in a partial range is a fundamental error. To achieve a 77% success rate in a uniform distribution, you need to scan 77% of the space.

I achieve this with 46% of the operations thanks to filtering. That's the actual math, not your interpretation.

This can be run in parallel on multiple cores. The dependency you mention doesn't exist because each worker manages its own range autonomously.

There's no communication between threads, only multiplied individual efficiency. You're still stuck on a generalized theory that doesn't apply here and doesn't invalidate the method, no matter how hard you try to distort it.

[kTimesG]

Confusing expected value N/2 with the cumulative probability of success in a partial range is a fundamental error. To achieve a 77% success rate in a uniform distribution, you need to scan 77% of the space.

I achieve this with 46% of the operations thanks to filtering. That's the actual math, not your interpretation.

I suggest you stop accepting the pure crap served to you by an AI that doesn't know how to count 1 to 10, and actually grasping basic math, like the definition of averages.


How the f*** did you end up with "77% probability of success with 46% effort" unless you are referring to a f**** average? This is completely embarassing, to have to explain to you what an average means.

Here: you scan N keys. You can find the key in the first try, or in the second try, or in the third try, or in the N-th try. Since it is equally likely to be anywhere, all of these possibilities have the same weight.

So, on average, you will find it after average(1 or 2 or 3 or 4 or ... or N tries) which, by the definition of averages, equals to (N * (N + 1) / 2) / N.

I'm gonna leave this thread because your non-sense is an insult to any basic common sense.

[mcdouglasx]

Confusing expected value N/2 with the cumulative probability of success in a partial range is a fundamental error. To achieve a 77% success rate in a uniform distribution, you need to scan 77% of the space.

I achieve this with 46% of the operations thanks to filtering. That's the actual math, not your interpretation.

I suggest you stop accepting the pure crap served to you by an AI that doesn't know how to count 1 to 10, and actually grasping basic math, like the definition of averages.


How the f*** did you end up with "77% probability of success with 46% effort" unless you are referring to a f**** average? This is completely embarassing, to have to explain to you what an average means.

Here: you scan N keys. You can find the key in the first try, or in the second try, or in the third try, or in the N-th try. Since it is equally likely to be anywhere, all of these possibilities have the same weight.

So, on average, you will find it after average(1 or 2 or 3 or 4 or ... or N tries) which, by the definition of averages, equals to (N * (N + 1) / 2) / N.

I'm gonna leave this thread because your non-sense is an insult to any basic common sense.

Code:

t time

# Experiment Configuration
TOTAL_SIZE = 100_000      # Total search space per block
BLOCK_REF = 4_096         # Reference unit for the jump distance
PREFIX_LENGTH = 3        # Target prefix length (e.g., 'abc')
SIMULATIONS = 10000      # 10k runs for statistical significance
FIXED_JUMP_RATE = 0.23   # Fixed 23% jump to match the 77% linear coverage
SECP_ORDER = int("0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141", 16)

def generate_h160(data):
    """Simulates address hash generation"""
    return hashlib.new('ripemd160', str(data).encode('utf-8')).hexdigest()

def linear_scan_77(dataset, target_hash):
    """Standard Linear Method: Scans exactly the first 77% of the range"""
    limit = int(len(dataset) * 0.77)
    checks = 0
    for i in range(limit):
        checks += 1
        if generate_h160(dataset[i]) == target_hash:
            return {"checks": checks, "found": True}
    return {"checks": limit, "found": False}

def prefix_jump_scan(dataset, block_ref, prefix_len, target_hash):
    """Prefix Methodology: Skips 23% of the reference block upon false prefix detection"""
    target_prefix = target_hash[:prefix_len]
    checks = 0
    i = 0
    dataset_len = len(dataset)
    while i < dataset_len:
        checks += 1
        current_hash = generate_h160(dataset[i])
        if current_hash == target_hash:
            return {"checks": checks, "found": True}
        
        # Heuristic skip logic
        if current_hash.startswith(target_prefix):
            i += int(block_ref * FIXED_JUMP_RATE)
        else:
            i += 1
    return {"checks": checks, "found": False}

def run_experiment():
    results = {
        "Linear 77%": {"found": 0, "total_checks": 0},
        "Prefix Jump": {"found": 0, "total_checks": 0}
    }
    
    print(f"--- STARTING SIMULATION: {SIMULATIONS} ITERATIONS ---")
    print(f"Comparison: Static 77% Cutoff vs. Heuristic 23% Jump")
    start_time = time.time()

    for s in range(1, SIMULATIONS + 1):
        # Generate random start point and target in the SECP256K1 space
        offset = random.randint(0, SECP_ORDER - TOTAL_SIZE)
        dataset = [offset + i for i in range(TOTAL_SIZE)]
        target_idx = random.randint(0, TOTAL_SIZE - 1)
        target_hash = generate_h160(dataset[target_idx])
        
        # Test 1: Linear
        res_l = linear_scan_77(dataset, target_hash)
        if res_l["found"]: 
            results["Linear 77%"]["found"] += 1
        results["Linear 77%"]["total_checks"] += res_l["checks"]

        # Test 2: Prefix Jump
        res_p = prefix_jump_scan(dataset, BLOCK_REF, PREFIX_LENGTH, target_hash)
        if res_p["found"]: 
            results["Prefix Jump"]["found"] += 1
        results["Prefix Jump"]["total_checks"] += res_p["checks"]

        if s % 1000 == 0:
            print(f"Progress: {s}/{SIMULATIONS}...")

    total_time = time.time() - start_time
    
    print("\n" + "="*85)
    print(f"FINAL BENCHMARK | Iterations: {SIMULATIONS} | Execution Time: {total_time:.2f}s")
    print("="*85)
    header = f"{'Methodology':<20} | {'Found':<8} | {'Total Checks':<15} | {'ROI (Success/Mh)'}"
    print(header)
    print("-" * len(header))
    
    for name, data in results.items():
        roi = (data["found"] / data["total_checks"]) * 1_000_000
        print(f"{name:<20} | {data['found']:<8} | {data['total_checks']:<15,} | {roi:>15.4f}")

if __name__ == '__main__':
    run_experiment()

Code:

Methodology          | Found    | Total Checks    | ROI (Success/Mh)
--------------------------------------------------------------------
Linear 77%           | 7662     | 476,335,471     |         16.0853
Prefix Jump          | 8106     | 483,915,592     |         16.7509

You criticize AI because it gives you the definitive proof, even making an exact comparison of your 77% linear, and prefixes with an adaptive jump of 23% to equalize conditions, I get in 10000 simulations an ROI of more than 4%, which mathematically proves that calling this "garbage" or "an insult to common sense" is simply refusing to accept that the heuristic extracts value from the prefix.

I'm not looking for 'the average,' I'm looking to maximize the find rate per million hashes.

But you say you're retiring, but you won't; you'll probably come back, with parallelization issues or N/2 theories poorly applied to the method because it's first-semester theory. In real cryptanalysis, I aim to maximize surface coverage. Numbers don't have feelings.

[kTimesG]

Learn to count. Your code is bullshit and makes no sense.

We're in a technical board of a cryptography, not on a Looney Tunes animated cartoon.

I doubt you'd actually grasp this code I wrote in two minutes, without asking your sweetheart ChatGPT to explain it to you, but here goes nothing.

Code:

import random

dataset = list(range(10000))
checks = []

for i in range(10000):
    random.shuffle(dataset)
    target = random.randint(0, 9999)

    for (k, v) in zip(range(7700), dataset):
        if v == target:
            checks.append(k + 1)

print(f'AVG checks per success: {sum(checks) / len(checks):.2f}')
print(f'Successes: {len(checks)}')

Code:

AVG checks per success: 3863.39
Successes: 7729

[mcdouglasx]

Learn to count. Your code is bullshit and makes no sense.

We're in a technical board of a cryptography, not on a Looney Tunes animated cartoon.

I doubt you'd actually grasp this code I wrote in two minutes, without asking your sweetheart ChatGPT to explain it to you, but here goes nothing.

Code:

import random

dataset = list(range(10000))
checks = []

for i in range(10000):
    random.shuffle(dataset)
    target = random.randint(0, 9999)

    for (k, v) in zip(range(7700), dataset):
        if v == target:
            checks.append(k + 1)

print(f'AVG checks per success: {sum(checks) / len(checks):.2f}')
print(f'Successes: {len(checks)}')

Code:

AVG checks per success: 3863.39
Successes: 7729

Your 'two-minute' code only demonstrates that you understand how a uniform distribution works in a shaken urn. Congratulations, you've rediscovered basic statistics (you've simplified everything with the cunning of a purist beast, failing to grasp the difference between counting and search optimization).

But the Bitcoin Puzzle isn't a shaken urn; it's an indexed range. My ROI isn't a counting error; it's the result of covering more ground through heuristic jumps. While you're getting excited because your average is N/2 (which is obvious since your post has nothing to do with the puzzle, hashes, or prefixes, nor does it directly compare the two), I'm focusing on the fact that my method finds more keys by processing the same range. You're confusing counting with optimization.

When are you going to understand that this is a heuristic search, which doesn't interfere with mathematics or cryptography? It's just a better way to search the space, and I prove it with the results that anyone can replicate as they wish, since you're so keen to discredit AI, even though the code obviously makes the comparison perfectly.