snip
My point is that you cannot be certain about what Bram did until he clarifies it himself. However, my search method remains more efficient, so one thing does not negate the other. To clarify, 'full random' is 100% random, and should not be confused with 'Random+Sequential,' which introduces a sequential component that may not be entirely random if we are precise.
Precision in terminology is crucial in programming.
edit:
I admit that it was a vague example. I wanted to tell you that 1024 h160 is not 100% valid proof to attest to what Bram did, but rather that his terms 'full random' are not correct, mathematically speaking.
No, you cannot say your search method remains more efficient because I do not know your search method. If it is 100% random as you describe, then you would have to find a private key in a 67 bit range to compare numbers with Bram's / other's methods.
That is pretty obvious that having only hash160 string we cannot see the private key directly can we?
So what I need actually to decode private key then?
I need a hex range boundary of Your address choice and the the resulting decimal string from step 6. or as You want convert it to an address back using brainwallet converter, so range boundary and an address
IS this a joke? You obviously need more than the range boundaries; you are asking people to provide you with step 6, which means they would have to know the private key. So how does this help any? With puzzles or life in general. The only people who would be intrigued are those who think you are doing something magical (and did not read everything you wrote) but in fact you are asking them to take their address's h160 and divide it by the private key (both in decimal format). If I know my private key, I don't need your tool. If I am chasing 68 or 69, your method does not help me because I obviously do not know the private key or I would sweep those funds lol.