The probabilities of finding close prefixes are not the same as finding distant ones. There is an average (not exact, but it exists), and the more keys you advance, the more likely you are to find another prefix. It is common sense. You are right that each individual event has the same probabilities, but they change in series of individual events together. I doubt you don't understand this, it's just that you don't like to admit it. For example, if someone discovers the pk of 67, you will say "it was luck!". They publish something, and you will look for hundreds of arguments to not give them credit. Debates like this are the same as debating with conspiracists and flat-earthers. To not admit they are right, you just need to counter-argue, and it is not necessary to be right to do that.

Why not? Did you empirically test this (if you do that, you will learn that you are wrong). And please don't say it's because of compound probability. I'm still waiting for you to give the references where compound probability refers to events occurring "next to each other" and not "both, but anywhere in a bunch of events".

If you visualize your range set as a circle, and arrange the keys (in any way you want), how the hell is it less likely to have two keys with same hash prefix next to each other, then spaced by whatever delta? The chances are the same once you count all of the combinations. You don't want to use a circle? Then you are in a fallacy again, because you forget about the previous and next ranges than the one you're analyzing browsing.

Now, the same applies when you do the calculations with "3 hashes next to each other" and so on, but in this context we are talking about the deltas between two keys, so let's stick to this.


You are suggesting that the chances to find another prefix increase WHILE you are iterating through the hashes. However, those chances are written in stone long before you ever begin to browse through the set, in whatever order you wish (sequential, reverse, random, scan jumping, flipping key bits, etc.)

I don't believe you can distinguish the difference between a Set and a List, or else it would be obvious why it never matters whether you find the "successes" next to each other or not.

Advancing or jumping by some average just because you found a hash, is simply just a good way of making the scanned ranges management a living hell. This is why @WP is simply using the found (longest I assume) prefixes of each well-defined subrange (like maybe 40-bits each) as a proof of work that he scanned the respective range (I'm 100% certain that there were subranges where he found more than the average number of estimated prefixes of whatever length, and ranges where he found less).

And this is also why I am confident he DID find a closer prefix than bilbilgin, simply because somewhere in some subrange, there was one prefix a little LONGER than some other that was "close by", against the "average chances" of them being so close. So I wouldn't play that bet.

Let me ask you a genuine question: if you change the generator of the curve (pick some other G), and you pick some 66-bit range (let's say, same range as Puzzle 67), and I give you a target address in that range, does the chances of finding hashes close by increase, decrease, or stay the same?

you are right, there is no such thing as compound probability, I made that up, there is no such term, there is no such thing as compound probability, it is always the same in all cases, that is why wp has found many very close prefixes, almost one next to the other, and bibilgin found 4 prefixes "1BY8GQbnueY" in a range of 1000000 keys (but it hides it), because it is equally probable, right.
those of you reading this have a hard time finding a long prefix are probably doing it wrong, because finding them nearby is just as probable as far away and that is the absolute truth. Happy?

If people like mcdouglasx, alberto and zielar approve of this topic, I can show you a small presentation example.

Or I can just write to them privately.

Edit;

I shared a small example with Gerbie. Due to his good-willed approach, a small presentation was sent. Gerbie, it would be right for him to explain the example himself.

My opinion on Random Search.

"There is only a PROBABILITY based on LUCK."

Since you put it back in the bag, PROBABILITY is the same and LUCK is the same in the system where Memory/Database is not recorded.

But here there are 2 types of PROBABILITY.

Independent probability and Dependent probability.

Independent Probability, after putting it back in the Bag, random selection result.

Dependent Probability, like shuffling the Bag, making the first selection from the left of the Bag, the next selection from the right or bottom. There are many variations of Dependent Probability effect triggered by the options.

What size search range were you using? It must have been a somewhat small one relative to GPU speed.


By not leaving the red beans out after grabbing one, on average, you double your attempts. Meaning, if you place the red bean back in the bag, you will find the green one, on average, every 100 attempts. By leaving the red bean out of the bag, you would find the green one, on average, every 50 attempts.


Why do you need approval of these people lol?! It is a community forum, post whatever you feel like, as you already have. Why not include ktimesg's name as well? Because he doesn't agree with you 100%? The one's you mentioned would not agree with you 100% either.

You would have to be really lucky to pick N distinct random keys in a N-sized set, where the events are all independent, and the starting conditions are identical at every draw.

In fact, there is an exact formula for this. and you can even know in advance with a very high degree of confidence how many times you'll get repeats, and after how many draws you'll start to get 3 repeats, and so on.

There is also the possibility that you'll never pick some of the numbers even after very very many draws (much larger than N). This is also something you can calculate at advance.

The only problem is that you can never know in advance what keys you'll miss, what keys will start to repeat, and things like that. But it is actually normal to have some keys picked up more often, and others less often, because these are the 99.(9)%... majority of cases in the combinational possibilities.

Your draws would just be one in such of the gazillions possibilities. So the possibility where you perfectly pick every random number without repeat is just a single one, out of those gazillion ones.

If you don't trust this information, just go ahead and do a full CDF and StdDev analysis on the history of any lottery you want (or just simulate one in Python). You'll see some numbers start to get repeated much more often while others remain behind in the histogram However, this is normal - they just landed in the universe where some specific combination occurred, there is no conspiracy. Oh, and also it might help you pick out the next lucky numbers. I'm kidding, not really, but maybe a couple of them.


Are you OK? You are putting words in my mouth. I never said compound probability does not exist, but I asked you twice already, and a final time now:

What reference do you have that states compound probability refers to two independent events occurring one after the other and not anywhere in the number of trials.

I can prove to you that what I said makes sense in practice, unlike you, who seems to read inexistent words in theories. Yes, finding them nearby or at distance D = whatever (pick any number you want for D), has the exact same chances.

Interesting thought experiment.
I did some calculations to help visualize the size of puzzle 67's keyspace. There are 73786976294838206464 possible keys in puzzle 67. Some may look at the number "73786976294838206464" or at the hex range of 40000000000000000:7FFFFFFFFFFFFFFFF and think, well that number doesn't really look that big.

Now let's take a look at the Great Pyramid of Giza, in Egypt. It is the largest pyramid in Egypt, with an original height of around 146.6 meters (480.6 feet) and a base length of about 230.4 meters (756 feet) on each side. Next, imagine you have 73786976294838206463 grains of just average, white, sand, and just 1 grain of black sand (representing all of puzzle 67's possible keys, and the 1 private key). You would fill the volume of the Great Pyramid of Giza with sand ~370 times. Try to picture 370 of these pyramids, all of white sand, and inside one of them somewhere is 1 individual grain of black sand.

If you took a typical US 5 Gallon bucket, and could check 1 bucket per second, looking for that 1 black grain of sand (and hopefully not miss it), that's about 1.5 billion grains of sand per second. It would take you 1560 years to check all of the sand, assuming you were checking nonstop, 24/7/365. Maybe a little bit longer, if you took a few breaks to eat some yogurt.

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

Example: some sequence of 100 events, and you know somehow that 2 of them are successful ones. It doesn't matter what we mean by "successful" (hash prefix match, or whatever you'd like to use).

Total possible sequence combinations: 4950
Total combinations where successes are next to each other: 99

So, the probability to have the successes next to each other is 99 in 4950.

Total combinations where successes are separated by a distance of 2: 98
Total combinations where successes are separated by a distance of 3: 97
Total combinations where successes are separated by a distance of 4: 96
...
Total combinations where successes are separated by a distance of 50: 50

So, the probability to have the successes separated by a distance of 50 is: 50 in 4950.

At this point, you would be something like: OK, this sounds like it's actually more likely to have the successes next to each other, rather than evenly spaced! So WTF is happening here?

Let's continue:

Total combinations where successes are separated by a distance of 51: 49
Total combinations where successes are separated by a distance of 52: 48
...
Total combinations where successes are separated by a distance of 98: 2
Total combinations where successes are separated by a distance of 99: 1

Maybe now something starts to become obvious: wait, so we only have 1 in 4950 as a probability to have the successes spaced by distance of 99? That doesn't sound right.

Well, friends, what we did is we forgot about what happened before our sequence and after our sequence. So, if we put head to head our sequence of events, we'll see that if the successes are at #1 and #100, they are "next to to each other".

So let's fix our probabilities:

Total combinations where successes are next to each other (or at dist 99): 99 + 1 = 100

So, the probability to have the successes separated by a distance of (1 or 99) is: 100 in 4950.

The same goes for the other ones, let's see what happens:

Total combinations where successes are separated by a distance of X (or 100 - X): 100 - X + X= 100

So, same chances whatever delta we pick.