Quote from: runlola on July 16, 2019, 03:04:07 AM

Quote from: Firebox on July 16, 2019, 02:32:13 AM

Quote from: runlola on July 16, 2019, 01:27:56 AM

Quote from: Firebox on July 16, 2019, 01:05:38 AM

Quote from: runlola on July 16, 2019, 12:45:22 AM

Interesting observation. I wonder if it's related to the method the puzzle creator used to create the keys:

Quote from: saatoshi_rising on April 27, 2017, 06:41:08 AM

There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty)

IMHO I think it is. Even if the creator of the puzzle didn't do it purposly the software he used most probably was adjusted to generate the most complicated keys within the each given range.

Sorry, but I think your math is actually wrong. You are using the range 1..2^bit to calculate the occurrence in the range, but you should be using the range 1..(2^bit - 2^(bit-1)). That would explain why all your results are occurring at > 50% of the range.

I was also wrong on part of my response. The range I stated (1..(2^bit - 2^(bit-1))) is the right cardinality (number of values), but the values given by that range are wrong. The range should be 2^(bit-1) .. 2^bit.

Not completely sure about the math, but I think the percentile for bit 60 using this range is

Code:

(1135041350219496382 - 2^59) / 2^60 = .48 = 48%

I've got your point, man. You mean the position of the hit number within the range 59->60. I was calculation the position of the hit number within the full range between 0->60.
Anyhow, both of this way maybe usefull to find any dependencies between the hit numbers. This is actually what I'm doing, I'm searching any common, let's call it coefficient, that can be used to narrow the search range for the hit number.
I understand that creator mentioned already that numbers were generated randomly, but I wanna try )). I believe that if any software was used to get this numbers there was definetly an algorythm used.