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

<p>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</p>

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

<p>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.</p>

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

<p>So no, there's no risk.</p>

CC BY-SA 3.0
2012-12-12T14:43:31.990Z
I meant to describe the risk to a Public Key Hash, which is different than the public key itself.  I updated the question.
makerofthings7
CC BY-SA 3.0
2012-12-12T21:32:21.157Z
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.
Highly Irregular
CC BY-SA 3.0
2012-12-13T10:37:50.613Z
@makerofthings7: The numbers are for finding a collision of the public key hash.
Meni Rosenfeld
CC BY-SA 3.0
2012-12-13T10:39:49.570Z
@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.
Meni Rosenfeld
CC BY-SA 3.0
2012-12-25T08:02:48.863Z
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)
makerofthings7
CC BY-SA 3.0
2012-12-25T09:15:28.323Z
@makerofthings7: Not sure what your point is. The RipeMD hash is a 20 byte number, meaning 160 bits. The address is a Base58Check encoding of this number (which includes a version byte and a checksum). There are 2^160 valid Bitcoin addresses. Each private key leads to one of them (for all intents and purposes, a random one).
Meni Rosenfeld
CC BY-SA 3.0
2012-12-25T15:34:21.593Z
Completely agree, I don't normally think in bits and made a mistake in my own math!  Thanks for the education and Merry Christmas / Happy Holidays!
makerofthings7
CC BY-SA 3.0
2012-12-12T06:44:02.973Z
2012-12-12T10:54:45.930Z
2012-12-12T10:54:45.930Z
Meni Rosenfeld
<p>As Bitcoin vanity pools become more popular, the possibility of using that power to derive <a href="https://bitcoin.stackexchange.com/q/5747/1878">another person's Base58 public key hash</a> becomes slightly more likely.</p>

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

<p>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</p>

<ul>
<li>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? </li>
</ul>

<p>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</p>

CC BY-SA 3.0
2012-12-12T06:37:31.140Z
Public key or private key?
Meni Rosenfeld
CC BY-SA 3.0
2012-12-12T07:30:23.977Z
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.
Stephen Gornick
CC BY-SA 3.0
2012-12-12T14:42:41.350Z
@StephenGornick - I intended to say Public Key Hash collision, which is the point of vanity pools.  I clarified the question.
makerofthings7
CC BY-SA 3.0
2012-12-13T10:37:04.420Z
@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.
Meni Rosenfeld
<mining-pools><vanity-address><balance><risk-mitigation>
What's the probability of vanity pools causing RIPEMD-160 (public key hash) collisions?
makerofthings7
# What's the probability of vanity pools causing RIPEMD-160 (public key hash) collisions?

(Asked by: username_0 on 2012-12-12)

As Bitcoin vanity pools become more popular, the possibility of using that power to derive [another person's Base58 public key hash](https://bitcoin.stackexchange.com/q/5747/1878) 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

**Tags:** mining-pools, vanity-address, balance, risk-mitigation

> **Comments:**
> **username_1**: Public key or private key?  
> **username_2**: 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.  
> **username_0**: @username_2 - I intended to say Public Key Hash collision, which is the point of vanity pools.  I clarified the question.  
> **username_1**: @username_0: 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.  

---

## 1 answers

### Answer by username_1 on 2012-12-12. Score: 8 | Accepted answer

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.

> **Comments:**
> **username_0**: I meant to describe the risk to a Public Key Hash, which is different than the public key itself.  I updated the question.  
> **username_3**: 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.  
> **username_1**: @username_0: The numbers are for finding a collision of the public key hash.  
> **username_1**: @username_3: 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.  
> **username_0**: 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)  
> **username_1**: @username_0: Not sure what your point is. The RipeMD hash is a 20 byte number, meaning 160 bits. The address is a Base58Check encoding of this number (which includes a version byte and a checksum). There are 2^160 valid Bitcoin addresses. Each private key leads to one of them (for all intents and purposes, a random one).  
> **username_0**: Completely agree, I don't normally think in bits and made a mistake in my own math!  Thanks for the education and Merry Christmas / Happy Holidays!  

---

