What I was imagining was that there could be a simple loop in the program. Start with the "first" private key (...001), go through the various hashing steps and see if you get a public address with the desired pattern. If not, then increment the private key by 1 (...002) and do the hashes again. That way, the attempted private keys would effectively get "burned" and not be reused.
It's like buying millions of lottery tickets in the same draw to try to cover as many numbers as possible. You might as well start with 1-2-3-4-5-6 and then 1-2-3-4-5-7 and so on methodically than to choose a bunch of random "pick 6" numbers. The chance to win is the same for any set of numbers, but there is a slight chance that a "pick 6" could be generated twice, thereby wasting the ticket (i.e. if you win, you would be splitting the jackpot with yourself). I suppose the "slight" chance is so slight that maybe it doesn't matter.
The entire security of Bitcoin, PGP, TLS/SSL, Tor, disk encryption, and all other crypto using fixed-length keys rests on the premise that the “slight” chance of a collision is
impossible as a practical matter.
Think: The probability of you picking the same key twice is equal to the probability of an attacker randomly picking your key in a bruteforce attack.
Theoreticians use terms such as “negligible probability” because such a thing is possible
in theory. But it will never actually happen that you generate the same key twice, unless your random number generator is so badly broken as to be worse than useless. Conceptually, think of randomly picking one drop of water from the ocean, then another, and getting the same drop; or randomly picking one grain of sand from anywhere on Earth, then another, and getting the same grain of sand.
2160 is much bigger than that.Whereas LoyceV speaks truly:
What I was imagining was that there could be a simple loop in the program. Start with the "first" private key (...001), go through the various hashing steps and see if you get a public address with the desired pattern. If not, then increment the private key by 1 (...002) and do the hashes again.
A fixed instead of truely random starting point would mean your private key isn't secure. It would mean anyone could reproduce your search and steal your coins.
Note, however, that Vanitygen does
try sequential points from a
randomly chosen starting point. (“Sequential” here does not mean linear “1, 2, 3”; rather, it uses elliptic curve point addition.) It does this for reason of efficiency. sipa’s keygrinder used in the current development branch of
segvan uses similar methods to rapidly generate a great quantity of keys (or optionally, tweaks) from a single random seed. This can be secure
if and only if all seed and key material other than the “winning” key is destroyed and never reused.
