Next scheduled rescrape ... never
Version 1
Last scraped
Scraped on 11/07/2025, 02:21:28 UTC

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.
Original archived Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Scraped on 04/07/2025, 02:21:34 UTC

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.