# What's the probability of vanity pools causing RIPEMD-160 (public key hash) collisions?

As Bitcoin vanity pools become more popular, the possibility of using that power to derive another person's Base58 public key hash becomes slightly more likely.

I'd like to know if anyone has done the math calculating probability of guessing a public key hash vs keys generated per hour.

In particular this information would be useful to defenders (and attackers) of accounts with large balances... Namely it may make sense from a risk avoidance strategy to keep large balances spread among several accounts for this reason

• So the question is, what is the horsepower required needed to crack someone else's key hash and what are the mitigating circumstances such as ASIC or FPGA availability?

If someone wants to take this a step further what is the maximum balance that should be held in an account based on those previous statistics

• Public key or private key? Commented Dec 12, 2012 at 6:37
• Now it is possible to create a vanity address that looks very similar to someone else's vanity address. But that still results in two completely separate private keys. Commented Dec 12, 2012 at 7:30
• @StephenGornick - I intended to say Public Key Hash collision, which is the point of vanity pools. I clarified the question. Commented Dec 12, 2012 at 14:42
• @makerofthings7: Another's person public key hash is public, there's no need to derive it, it's already in the open. The problem is with deriving a private key which maps to this public key hash. This has essentially 0 chance of happening unintentionally. As for it happening intentionally, the chance is still negligible as detailed in my answer. Commented Dec 13, 2012 at 10:37

Bitcoin addresses are 160-bit numbers. Hence, randomly finding a private key corresponding to an address takes on average 2^160 attempts.

If 4 billion computers work on cracking a key doing 1 billion calculations per second for 15 billion years, they will find a total of 1.8*10^36 keys, so their chance to hit a right one is

(1.8*10^36)/(2^160) = 1.23 * 10^(-12)

which is one in a trillion. And this is only if they intentionally try to crack keys. If they just run normal vanity calculations, it doesn't matter how many keys they go over, as they'll eventually report just one key.

In the future (when the above figures may be slightly less ridicuolous), we might move on to longer key hashes.

So no, there's no risk.

• I meant to describe the risk to a Public Key Hash, which is different than the public key itself. I updated the question. Commented Dec 12, 2012 at 14:43
• If I understand it correctly, these calculations are assuming you're trying to get one particular private key, but actually there are LOTS that would be desirable. Of course, the process of actually determining whether a particular key is of value or not may mean twice as much (or more) processing time. Commented Dec 12, 2012 at 21:32
• @makerofthings7: The numbers are for finding a collision of the public key hash. Commented Dec 13, 2012 at 10:37
• @HighlyIrregular: I think you could make an ASIC that generates addresses and matches them against a hashtable of valuable addresses. Then instead of the chance to find a collision, you'd speak about the expected value obtained from cracked addresses, which is at most 21 million BTC times the probability mentioned above. Commented Dec 13, 2012 at 10:39
• I think a small correction to your math may be needed... Bitcoin addresses are based on the 20 byte RIPE-MD part... where the Bitcoin address is based on Base58Check... (The rest is a checksum and a leading network ID) Commented Dec 25, 2012 at 8:02