Bitcoin puzzle transaction ~32 BTC prize to who solves it

[puzzlemandelux]

I am looking for puzzle 67, working with the prefixes.
Obviously I understand there is probably no correlation with the prefixes but I have collected up to 1BY8GQbnu so far.
Currently looking for 1BY8Qbnue.

Working with a 4070 Super and Vanbitcracken.
2000 million keys per second.

Any other software that would be quicker for this work?

[mcdouglasx]

Again, you are using the words "occur in sequence" which is not the same as "occur in a sequence". There's nothing in that book about this.

You're still assuming the probability changes just because you move from one key to the next. But there's no external entity that would do that (except faith maybe).

As I told you previously, you never want to lose your argument and you will always find a explanation that fits with what you preach. And I am the one quoting thinks while you only preach your words as true. It's great you read the book in less than 24 hours. However, when talking about events that 'occur in sequence', I mean that the events appear one after the other in a specific order. It doesn't necessarily mean that one depends on the other, but rather that there is an order. This is a typical fallacy in debates. You dismiss opposing ideas in a disparaging way to validate your point by saying things like 'except faith maybe'.


"A compound event is also the outcome of an experiment, but can be broken down into a combination of simple events occurring simultaneously or in succession."
https://study.com/academy/lesson/compound-event-in-math-definition-example.html

https://thirdspacelearning.com/gcse-maths/probability/combined-events-probability/#:~:text=Combined%20events%20in%20probability%20are,use%20the%20AND%20probability%20rule.

https://www.youtube.com/watch?v=EHU6pVSczb4

If we want to find a RIPEMD-160 hash with 4 initial prefixes, for example:

123a

The probability of each independent character is 1/16 (since a hex has exactly 16 alphanumeric characters 0-9 a-f). So, the probability of the complete prefix 123a would be:

1/16 x 1/16 x 1/16 x 1/16 =  1/65.536.

And that's just the calculation for a 4-digit prefix. With 2 prefixes, it increases much more, and if you look for longer prefixes, it becomes even less probable.

Therefore, due to the uniform distribution of hashes, it is less likely that we will find a prefix close to another one.

A probabilistic software using a previous prefix as a reference point, where you skip millions of keys and where a coincidence or collision is less likely, is not a waste of time as you suggest. Instead, it would be another probabilistic option. In this case, where sequential brute force is exponentially demanding, a probabilistic search suggests a better strategy.

However, it is clear that you can skip the address, but it is less probable if you do the calculations correctly, adding a margin of error.

[kTimesG]

Therefore, due to the uniform distribution of hashes, it is less likely that we will find a prefix close to another one.

A probabilistic software using a previous prefix as a reference point, where you skip millions of keys and where a coincidence or collision is less likely, is not a waste of time as you suggest. Instead, it would be another probabilistic option. In this case, where sequential brute force is exponentially demanding, a probabilistic search suggests a better strategy.

I'm not preaching anything that's not in a 9th grade high school math book where I live.

Did you read the definition of a uniform distribution? It's a random oracle where anything can happen (with an equal chance of course, which is all I'm bragging about for the last 10 posts here), not something that will ever follow any kind of even-spaced value-to-slot allocations, no matter how you look at it, analyze it, or whatever you want to do with it. The "margin of error" when trying to predict anything about it is simply equal to keeping track of skipped key ranges, which is where everyone that attempts to use this "theory" will end up to, once they find that they either have too many or too few prefixes found.

Just because the probabilities are all equal, does not mean that you will end up with an equal amount of same values over some microscopic sample size (like any 2**66 sample out of comb(2**160, 2**66), or rather, out of (2**160) ** (2**66) possibilities, since any hash has an equal probability to occur).

It is exactly the same principle why, if you throw a coin 100 times, the chances to get a 50/50 is extremely unlikely, even if it has the highest chances. Or isn't a coin flip an uniform distribution of 50/50? Why wouldn't RIPEMD-160 be the same, if you scan some range, and only count how many times the first bit is 1, there's basically 0% chances to have anywhere near the same amount of hashes that start with a 0 (the difference will be a really really big number, not close to zero, and there's a 99.9% confidence for this really big difference to occur). Only when the number of flips (number of hashes) goes to infinity, will you ever have an exact ratio of 50% 0s (heads) and 50% 1s (tails). Up to that  point, the difference (in absolute value) will almost certainly increase further and further, perhaps at some times swapping whether the 0s or the 1s start to go ahead. It's all a probability race based on equal chances of possible occurrences.

Thanks for the lesson that 2 bytes can hold 65536 distinct values.

[madogss]

hello. Can I ask you a question about kangaroos? using the example of the kangaroo RC.
When the program starts, the total number of kangaroos is displayed - 1507328 kangaroos, Speed: 2271 MKeys/s - do I understand correctly that the speed is indicated for each kangaroo?

no its all the kangaroo's combined.

[brainless]

Let me explain in detail everything related to transaction replacement, particularly focusing on Replace-by-Fee (RBF) and how it works in the Bitcoin network. I will also cover the process of replacing transactions, the use of RBF, and how to manage transactions in different scenarios.

What is Replace-by-Fee (RBF)?
Replace-by-Fee (RBF) is a feature that allows a user to replace a Bitcoin transaction that has not yet been confirmed by the network with another transaction that pays a higher fee. This can be helpful in case the original transaction was not included in the next block due to low fees, especially in times of network congestion.

When RBF is enabled, the sender can increase the fee and re-broadcast the transaction, increasing the chances of it being included in the next block by miners.

How RBF Works:
Transaction Broadcasting: A user broadcasts a transaction with a specified fee. If the transaction is not confirmed (due to low fees or network congestion), the user can replace the original transaction with one that has a higher fee.
RBF-Compatible Transactions: Transactions that are sent with RBF enabled are considered "RBF transactions". These transactions have a special flag in their structure that allows them to be replaced.
Why Replace a Transaction?: If a user sends a transaction with low fees and it’s stuck in the mempool (not confirmed), they can increase the fee to make the transaction more attractive to miners. Miners prioritize transactions with higher fees.
How to Create and Replace Transactions with RBF:
1. Creating a Transaction with RBF Enabled:
To send a transaction with RBF enabled, the wallet or software you are using must support RBF. Most modern Bitcoin wallets, including Bitcoin Core, allow you to enable or disable RBF when creating transactions.

Steps in Bitcoin Core (GUI):
Open Bitcoin Core and go to the Send tab.
Select the address to send the Bitcoin to and enter the amount.
If RBF is available, you can check a box or select an option to enable Replace-by-Fee. This flag ensures that the transaction can be replaced with a higher fee later.
Sign and broadcast the transaction.
Steps in Bitcoin Core (Command Line):
You can also use Bitcoin Core’s command-line interface to create an RBF-enabled transaction.

bash
Copy
bitcoin-cli createrawtransaction '[{"txid":"previous_txid","vout":0}]' '{"recipient_address":amount}'
To enable RBF, you can use the following command:

bash
Copy
bitcoin-cli sendtoaddress "recipient_address" amount "" "" true
Here, the true value at the end enables RBF for this transaction.

2. Replacing a Transaction:
If the transaction you sent was not confirmed due to low fees, you can replace it with a new transaction that has a higher fee. This is where RBF comes into play.

Steps to Replace a Transaction:
Identify the transaction: You need the Transaction ID (TXID) of the original transaction that is stuck.
Create a new transaction: Use the same inputs (unspent transaction outputs, UTXOs) as the original transaction, but increase the fee.
Rebroadcast the transaction: Once the new transaction is created and signed, rebroadcast it to the network. Since it has a higher fee, it will be more attractive to miners and is likely to be confirmed faster.
3. Using Bitcoin Core Command Line to Replace:
You can use the following command to replace a transaction using RBF:

bash
Copy
bitcoin-cli walletcreatefundedpsbt '[{"txid":"previous_txid","vout":0}]' '{"recipient_address":amount}' 0 false
The false option ensures that RBF is not enabled. You can set true if you want to enable RBF during the creation of this transaction.
After creating the transaction, sign and broadcast it to the Bitcoin network.
4. How to Replace an Unconfirmed Transaction:
If you are using a wallet that supports RBF, you can also replace a transaction using the wallet’s interface or an API. Some wallets will automatically allow you to increase the fee of an unconfirmed transaction directly from their UI (like Electrum).

What Happens if the Transaction Doesn't Support RBF?
If a transaction is not RBF-enabled, it cannot be replaced once broadcast to the network. The transaction is considered final once it's broadcast, and the only option is to wait for it to be confirmed or rejected by the network.

Non-RBF transactions cannot be modified or replaced.
Once a non-RBF transaction is broadcast, it is essentially locked in place, and only the miners can choose whether or not to include it in a block.
How to Check if a Transaction Supports RBF?
You can check if a transaction is replaceable by looking at the raw transaction data or by querying the Bitcoin node or blockchain explorer.

In Bitcoin Core: You can use the command getrawtransaction to check whether the transaction supports RBF. If the transaction contains the "replaceable" flag, it is replaceable.
bash
Copy
bitcoin-cli getrawtransaction "TXID" 1
Blockchain Explorer: Many blockchain explorers show whether a transaction is RBF-enabled. You can check the status of the transaction by entering its TXID into the explorer.
Example Scenario:
Let’s say you send a transaction with a low fee and it doesn't get confirmed after several blocks. In this case:

You check the status of your transaction using a blockchain explorer.
If the transaction is still in the mempool (unconfirmed), you can create a new transaction that replaces the original transaction with a higher fee (thanks to RBF).
You broadcast the new transaction, and since it pays a higher fee, miners are more likely to confirm it.
Why Use Replace-by-Fee?
Speed Up Transaction Confirmation: If your transaction is stuck due to low fees, RBF allows you to increase the fee and get it confirmed faster.
Network Congestion: In times of high network traffic, RBF gives you a way to "boost" your transaction's priority by increasing the fee, ensuring it doesn’t stay stuck.
Avoid Stuck Transactions: For users who want more control over their transaction's confirmation, RBF provides the flexibility to adjust the fees dynamically.
Summary:
RBF (Replace-by-Fee) allows you to replace an unconfirmed transaction with a higher-fee transaction.
Enable RBF during the creation of a transaction in compatible wallets like Bitcoin Core.
Replace transactions with higher fees if they are stuck in the mempool.
Non-RBF transactions cannot be replaced once broadcast to the network.
Check if a transaction supports RBF using raw transaction data or a blockchain explorer.
RBF provides flexibility for users to manage their transactions and avoid delays caused by network congestion.

Your choice for enable or not RBf in tx ended
Each n every tx you send to mempool, by default set RBf enabled at minners (mempool)
Read Bitcoin core current rules

[karrask]

hello. Can I ask you a question about kangaroos? using the example of the kangaroo RC.
When the program starts, the total number of kangaroos is displayed - 1507328 kangaroos, Speed: 2271 MKeys/s - do I understand correctly that the speed is indicated for each kangaroo?

no its all the kangaroo's combined.

why is the speed so low for just math? keyhant (bsgs) is much faster with enough RAM and processor threads.
do you know where to find the fastest algorithm for obtaining a public key and address? maybe someone has, can you share?

[kTimesG]

hello. Can I ask you a question about kangaroos? using the example of the kangaroo RC.
When the program starts, the total number of kangaroos is displayed - 1507328 kangaroos, Speed: 2271 MKeys/s - do I understand correctly that the speed is indicated for each kangaroo?

no its all the kangaroo's combined.

why is the speed so low for just math? keyhant (bsgs) is much faster with enough RAM and processor threads.
do you know where to find the fastest algorithm for obtaining a public key and address? maybe someone has, can you share?

BSGS shows speed of how many keys are not a solution, it doesn't compute any of them except one in every sqrt(interval_size) keys. Think of it like you have a really big table of divisors (RAM) for some number, and then checking whether you can find some number (the solution) which is the inverse of the divisor. Because of the math, you can dismiss an entire sqrt(N) subinterval by just doing a single check after some simple multiplication or whatever.

Kangaroo shows speed of keys that are actually being computed. It doesn't require any RAM, just a small constant storage. It can solve the types os problems for which there isn't enough RAM on planet Earth to run a BSGS algorithm (like any puzzle above 100 bits more or less).

It doesn't matter that you see BSGS speeds of petakeys/s because the interval size is so huge that this "speed" is totally useless. You should probably divide that "speed" by sqrt(N) to have a fair comparison with a Kangaroo speed.

We don't have a fastest algorithm to do what you want, otherwise this thread would be dead since many years ago. And probably all cryptos would have a value of zero since they'd be broken.

The speed is low because you don't have a fast enough computing device. No one has a magic unicorn chip that does ECC math for free, without wasting power and dissipating heat.

Which one is better? They both have the same actual real speed, but BSGS requires RAM which you might not have enough of (the type of amounts that would require an entire solar system, if you go for higher puzzles)

[mcdouglasx]

I'm not preaching anything that's not in a 9th grade high school math book where I live.

Do you think this is the best way to win the debate? You're going off on a tangent and I don't think you're the one making shadow-posting (when a user overlays previous chats with long text to hide old chats, usually using alternate accounts).
I'd like you to give real mathematical proofs, like I did, this is a post to share ideas about the puzzle, not to impose our own, just because.

[bibilgin]

My friend mcdouglasx, don't bother yourself.

Someone who has the ability to look down on people rather than the desire to learn. The image of appearing knowledgeable by writing long articles does not always hold up.

A person who cannot even answer simple questions is writing via CHATGPT or another AI.
Let's get back to our topic. He is not interested in anything below 100 bit wallets anyway. (We can ignore that.)

What can we do for solutions and new ways?

[kTimesG]

I'm not preaching anything that's not in a 9th grade high school math book where I live.

Do you think this is the best way to win the debate? You're going off on a tangent and I don't think you're the one making shadow-posting (when a user overlays previous chats with long text to hide old chats, usually using alternate accounts).
I'd like you to give real mathematical proofs, like I did, this is a post to share ideas about the puzzle, not to impose our own, just because.

Lol, you are basically asking for a mathematical proof that all possible combinations stand an equal chance. But this is by definition, and everything else is simply a consequence.

Look, I'm not using ChatGPT or AI, because I have a working brain instead, and a finished college. But that should not matter here.

I don't really understand where you are starting to disagree with the below statements. Maybe you can enlighten whoever reads our debate, where exactly the movie starts to break:

1. RIPEMD-160 is a hashing algorithm, and as such, just like you said, implies an uniform distribution. If you don't agree, why not?

2. All hashes are independent of one another, e.g. any single time you do a hash, you have an equal chance of getting any one of the possible 2**160 hashes. Agree? If not, why?

3. For some random set of events (let's say, of length 2**66), this means any one of those 2**66 events can end up with any one of the possible 2**160 hashes. Agree? If not, why?

4. If you agree with 3, then there are 2**160 (possible hashes) raised to the power 2**66 (number of events) possible combinations that exist. Therefore, the random samples set (of length 2**66) is somewhere in these astronomically huge possibilities. Agree? If not, why?

5. If you agree so far, then you accept the fact that all of those 2**66 hashes in your set may all have the same value (because this is a valid combination). Agree? If not, why?

6. In the same way, all of the hashes may be different, or you may have an arbitrary number of repeated values. Agree? If not, why?

7. If you agree so far, then why would you think that your specially chosen set has some whatever hash appearing just once, or twice, or whatever amount of times? OK, you will say that it is less likely for that to happen, because 2**160 is much greater than 2**66, and you would be completely right about that.

In fact, this is exactly what a CDF (cumulative distribution function) and PMF (probability mass function) computes: These functions take three parameters:

- number of trials (e.g. 2**66 events)
- a number for which you'd like to know how many times (or up to how many times) some variable can occur (be a success) after those number of trials were performed in a randomly, uniform, independent manner
- the probabilities of success of the event(s) (in our case, all hashes have the same chance of occurring, every time)

If you notice, none of the above ever implies any kind of events order or events inter-dependency, because of #1 in effect. All that matters is how often you would expect something to occur, or to repeat itself.

Now, CDF and PMF directly take into account ALL POSSIBLE combinations that can occur. Because we have 2**160 raised to 2**66 possibilities (a number that is 160 x 2**66 bits in size), computing the CDF is impractical, if not impossible without a supercomputer).

However, you can play around with much less parameters, and observe the resulted probabilities dependning on what arguments you wish to get a result for.

You can use Python with scipy.stats.binom to play around with smaller values, and test your theories on rolling a dice. Or playing a virtual lottery. If you manage to somehow predict the dice rolls, or predicting the lottery numbers (just because, well, uniform distribution and etc.), you are my hero!

In reality, all you'll get is that independent events running off an uniform distribution simply produce noise, and there is no actual uniformity in the results. You will get different results every time. What I don't understand, is why would anyone think that things change at the slightest, when the size of the problem changes (like, for example, using the first however few first bits of a hash). They do not, and the only real answers to questions are only found if fully determining the values in the set (in english: full range scanning).

[mcdouglasx]

snip~

Thanks! With your math skills, you've just exposed the pioneer creators of vanity address software by estimating how often you're likely to encounter an N-character prefix. They should be ashamed of themselves for implementing an inefficient calculation.

A person who cannot even answer simple questions is writing via CHATGPT or another AI.

There is a downside to AI, they often struggle with probabilities due to their counterintuitive nature.

[mjojo]

I hope 67 solved asap to finished foolish discussion (pro / con) about prefix

[karrask]

hello. Can I ask you a question about kangaroos? using the example of the kangaroo RC.
When the program starts, the total number of kangaroos is displayed - 1507328 kangaroos, Speed: 2271 MKeys/s - do I understand correctly that the speed is indicated for each kangaroo?

no its all the kangaroo's combined.

why is the speed so low for just math? keyhant (bsgs) is much faster with enough RAM and processor threads.
do you know where to find the fastest algorithm for obtaining a public key and address? maybe someone has, can you share?

BSGS shows speed of how many keys are not a solution, it doesn't compute any of them except one in every sqrt(interval_size) keys. Think of it like you have a really big table of divisors (RAM) for some number, and then checking whether you can find some number (the solution) which is the inverse of the divisor. Because of the math, you can dismiss an entire sqrt(N) subinterval by just doing a single check after some simple multiplication or whatever.

Kangaroo shows speed of keys that are actually being computed. It doesn't require any RAM, just a small constant storage. It can solve the types os problems for which there isn't enough RAM on planet Earth to run a BSGS algorithm (like any puzzle above 100 bits more or less).

It doesn't matter that you see BSGS speeds of petakeys/s because the interval size is so huge that this "speed" is totally useless. You should probably divide that "speed" by sqrt(N) to have a fair comparison with a Kangaroo speed.

We don't have a fastest algorithm to do what you want, otherwise this thread would be dead since many years ago. And probably all cryptos would have a value of zero since they'd be broken.

The speed is low because you don't have a fast enough computing device. No one has a magic unicorn chip that does ECC math for free, without wasting power and dissipating heat.

Which one is better? They both have the same actual real speed, but BSGS requires RAM which you might not have enough of (the type of amounts that would require an entire solar system, if you go for higher puzzles)

Thank you for the clarification. I wanted to understand the difference between a keyhant and a kangaroo. as for the fastest algorithm, I meant which is the fastest at the moment, not in theory.
 I have an idea and I would really like someone to tell me about kangaroo's work. need the core of the algorithm and not much information to change the jumping mechanics.  also need an algorithm for calculating the bitcoin address.
 Can you help me ?

How are the kangaroo starting points calculated? what data (values) does the program use? what value is the public key converted from?

[kTimesG]

snip~

Thanks! With your math skills, you've just exposed the pioneer creators of vanity address software by estimating how often you're likely to encounter an N-character prefix. They should be ashamed of themselves for implementing an inefficient calculation.

It would have been more productive to simply pinpoint where you started to disagree.

But you are correct: the calculation of how often you're likely to encounter an N-character prefix is an estimation indeed! Good catch! So, you agree that a uniform distribution does not mean that you get evenly-spaced same-size predictable amounts of prefixes, so you are on a good path.

[mcdouglasx]

snip~

Thanks! With your math skills, you've just exposed the pioneer creators of vanity address software by estimating how often you're likely to encounter an N-character prefix. They should be ashamed of themselves for implementing an inefficient calculation.

It would have been more productive to simply pinpoint where you started to disagree.

But you are correct: the calculation of how often you're likely to encounter an N-character prefix is an estimation indeed! Good catch! So, you agree that a uniform distribution does not mean that you get evenly-spaced same-size predictable amounts of prefixes, so you are on a good path.

I don't need to answer 1,000 lines of a questionnaire where you only talk about the hashes themselves. That's all you've discussed, just the simple theory. It's absurd, it strays from the main topic, which is the probability of a prefix of N characters repeating within an estimated range and why it's less probable for this to occur relatively close to another. You're skipping over compound probability, Poisson distribution, statistical frequency. In short, you're misinforming the forum just to be right, and AI are terrible at reasoning.

Everyone here already has the general answer; it's not necessary to know mathematics to deduce that when you're looking to find a given prefix, the longer it is, the less likely you are to find it nearby than far away.

Why is it less likely to find identical prefixes that are close together?


Due to the random nature and independence of events, the probability that two rare events (like finding a specific long prefix) occur in nearby positions is extremely low. This is because we not only need a rare event to happen but for it to happen twice in a short space, which is even more unlikely. Therefore, in the case of probabilistic software, we use compound probability to calculate the probability of a given prefix appearing and the Poisson distribution to estimate the expected frequency of rare events(long prefix) over a wide range.


And yes, before you search in AI, two independent events, unrelated to each other, each maintains their own identical probabilities. But they change like when you flip 2 or more coins trying to get both heads.

Exercise:

Two subjects head to a casino, subject A called 'Near' bets with subject B that we will call 'Far'.

Far bets Near $1000 that he won't flip 3 coins and have all of them result in heads. Who has a higher probability of winning, Near or Far?

[kTimesG]

I don't need to answer 1,000 lines of a questionnaire where you only talk about the hashes themselves.

RIPEMD-160 was purely an example. What stops you from simply using the first 58 bits instead (let's call this a hash prefix)? What stops you from using just the first bit of the hash? They're all uniform, independent bits, or are they not?

Let's talk a bit about Poisson, since you brought it up. It is used to estimate the CDF when the number of possibilities is extremely large (hence, it's an estimated probability, not an exact one, careful). Using Poisson, can you please tell us, if we want a degree of confidence of let's say >= 90%, how many hashes in a 66-bit range start with some whatever 10-prefix base58?

It's a simple question, that might reveal how far away from the "average" the amount of prefixes are likely to be.

Obviously, the answer is somewhere between 0 and 2**66 included, because that is the only interval where the confidence reaches 100%. I am really interested on what you come up with as a result.

And yes, before you search in AI, two independent events, unrelated to each other, each maintains their own identical probabilities. But they change like when you flip 2 or more coins trying to get both heads.

Unfortunately, unlike many others around here, I'm not using any AI to produce crap statements or crackpot theories.

Exercise:

Two subjects head to a casino, subject A called 'Near' bets with subject B that we will call 'Far'.

Far bets Near $1000 that he won't flip 3 coins and have all of them result in heads. Who has a higher probability of winning, Near or Far?

I thought we were talking about having some estimated amount of prefixes in some range, and whether it's more or less likely for them to be close to each other, rather than semi-arbitrarily spaced through the range. Pardon me, what do Near or Far have to do about this?

[m1k1]

I have been scalping this forum for 2 weeks now. I made an account just to tell ALL of you that there is no need to "out-math" one-another. Just do your way of finding the keys. Once you find them, brag about how you are the superior mega-mind that rules all of BTC. Just do the puzzles and don't trashtalk each other in the process. -M1

[madogss]

Thank you for the clarification. I wanted to understand the difference between a keyhant and a kangaroo. as for the fastest algorithm, I meant which is the fastest at the moment, not in theory.
 I have an idea and I would really like someone to tell me about kangaroo's work. need the core of the algorithm and not much information to change the jumping mechanics.  also need an algorithm for calculating the bitcoin address.
 Can you help me ?

How are the kangaroo starting points calculated? what data (values) does the program use? what value is the public key converted from?

You will want to look at papers published for a deeper understanding or look at the kangaroo discussions on here but for basic understanding kangaroo has 2 types tames and wilds together they are a herd usually 1 tame and 2 wilds you can look at jeanlucpons or retiredC's readme for what they chose, tames jump to a random point then increment sequentially recording every point they land on while wilds jump from random point to random point not recording anything until they run into a tame then they hash and if the public key matches wow you found the key but if not then you get a dead kangaroo.

[albert0bsd]

How are the kangaroo starting points calculated? what data (values) does the program use? what value is the public key converted from?

Kangaroo is faster trustme, algorithm is difficult to explain at first glance.

As some other users explain before

Tame kangaroos jumps pseudo-random but deterministic from a know point like Start Base range (0x7......) or any other know value near our target publick key, so each time that a DP point (Distinguished Point with some amount of bits in ZERO in the X coordinate) is found we know its exact value.

In the other hand Wild kangaroos jumps pseudo-random but deterministic from an UN-know point like the target key, so each DP value that we found we only knows its relative value to our target key.

So the bigger dataset for tame or wild DP we have more probabilities that one item in one dataset is found in the another dataset, one that you found a match you automatically can translate all the Unknown DP into its real value this include the TARGET UNKNOWN PUBLIC KEY.

According to the birthday paradox such collision must occur soon of later so you with math/statics can calculate what are those odds for each new found value. Those odds grown exponentially.

Remember in the original birthday paradox in a room with 25 random people the probabilities that two of them have the same day of birthday are near 50%.

[Geshma]

Therefore, due to the uniform distribution of hashes, it is less likely that we will find a prefix close to another one.

A probabilistic software using a previous prefix as a reference point, where you skip millions of keys and where a coincidence or collision is less likely, is not a waste of time as you suggest. Instead, it would be another probabilistic option. In this case, where sequential brute force is exponentially demanding, a probabilistic search suggests a better strategy.

I'm not preaching anything that's not in a 9th grade high school math book where I live.

Did you read the definition of a uniform distribution? It's a random oracle where anything can happen (with an equal chance of course, which is all I'm bragging about for the last 10 posts here), not something that will ever follow any kind of even-spaced value-to-slot allocations, no matter how you look at it, analyze it, or whatever you want to do with it. The "margin of error" when trying to predict anything about it is simply equal to keeping track of skipped key ranges, which is where everyone that attempts to use this "theory" will end up to, once they find that they either have too many or too few prefixes found.

Just because the probabilities are all equal, does not mean that you will end up with an equal amount of same values over some microscopic sample size (like any 2**66 sample out of comb(2**160, 2**66), or rather, out of (2**160) ** (2**66) possibilities, since any hash has an equal probability to occur).

It is exactly the same principle why, if you throw a coin 100 times, the chances to get a 50/50 is extremely unlikely, even if it has the highest chances. Or isn't a coin flip an uniform distribution of 50/50? Why wouldn't RIPEMD-160 be the same, if you scan some range, and only count how many times the first bit is 1, there's basically 0% chances to have anywhere near the same amount of hashes that start with a 0 (the difference will be a really really big number, not close to zero, and there's a 99.9% confidence for this really big difference to occur). Only when the number of flips (number of hashes) goes to infinity, will you ever have an exact ratio of 50% 0s (heads) and 50% 1s (tails). Up to that  point, the difference (in absolute value) will almost certainly increase further and further, perhaps at some times swapping whether the 0s or the 1s start to go ahead. It's all a probability race based on equal chances of possible occurrences.

Thanks for the lesson that 2 bytes can hold 65536 distinct values.

Bitcoin block 756951 has the lowest SHA256 hash to date: 0000000000000000000000005d6f06154c8685146aa7bc3dc9843876c9cefd0f. Generating a hash this low has the same likelihood as flipping a coin 97 times in a row and it landing on tails every time.