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.