I'm not saying my method "wins". I'm saying that on average prefix theories have EXACTLY the same speed as a linear search. Which this script demonstrates beautifully.
My only issue with this statement, is that you and ktimes have chit all over h160 partial matches, and anyone who says anything about a prefix lol, saying they are useless. At worse, they divide the range up differently than what you are doing, range / x = y subranges.
Let's clarify what I mean by useless : They do not provide a statistical edge over a linear search, but makes the code you have to write more complex, and potentially not GPU friendly. It's only drawbacks in my opinion.
Appologies if anyone thought they were shat on. My intention was not to hurt but to let people know there is no magic statistical edge there.
Lol, more complex and not GPU friendly? How so? I bet my entire code, search program, client, and server, is just as friendly, if not more, than yours. You obviously have something built into yours to find PoW h160 matches, but for 67, it was a whole different h160 than the target key; nothing right or wrong with that. Mine simply checks for x matching h160 characters of the target key provided.
And I believe if you read back, a few already agreed/stated, there was no magic statistical edge. (Can't speak for Bibil though lol)
Hmmm... but how can something that does not add any value in any way be called something else than "useless"?
Come on ktimesG, that statement is windier than a sackful of farts lol.
Does selecting random subranges, then searching sequential in that subrange, add any value over starting at the beginning key of the entire range and searching until the last key of the range? Oh sure, bend it like you all did before saying, uhhhh your competition will know what you are doing and just start somewhere else or at the opposite end, etc. But no one knows what anyone is doing, other than a public pool. Bram does not disclose his current stats anywhere, publicly. So I guess random subranges is useless too lol.
If I find some hash that has 67 matching bits with the target hash (67 front bits, or 67 tail bits, or some whatever 67 bits matched in some combination of 67 out of 160 positions I want to pick), then whom/what/why/how does that influence in any way the probability of the next key that I'll check (be it k + 1 or some other k), to NOT have all the 160 bits of the target hash matching?
Stats, data, tests, tell me that it is 99.99999999999% not gonna happen lol. Run the public data that Bram provided for his PoW keys. How many were back to back in sequential order? Stop beating this dead horse. It's a risk/reward. For the 69 puzzle (in a 68 bit range), you would find maybe 2 h160 matches with 67 matched bits, in sequential order. Pretty small chance that it would be the actual h160 I am looking for. A risk I would definitely take 7 times each day and 45 times on Tuesday.