<p><a href="https://bitcointalk.org/index.php?topic=25804.0">VanityGen</a> uses the GPU to generate addresses until a desired match is found. On my 5870 it does about 27 million addresses per second.</p>

CC BY-SA 3.0
2011-11-30T00:55:14.380Z
So about 1.4 billion years to find two keys with the same address. That would allow you to have an address whose coins you could claim with two different keys, which would do no harm whatsoever.
David Schwartz
CC BY-SA 3.0
2011-12-01T00:49:43.983Z
@DavidSchwartz Add Moore's law to it and we end up at around 45 years (1.4billion ~ 2^30, 30 doublings at the rate of 1.5 years each).
ThePiachu
CC BY-SA 3.0
2011-12-01T02:52:47.987Z
Yep. It's quite possible that within 40 years or so, someone will have two private keys that can each claim Bitcoins sent to the same address. (The challenge of claiming anyone else's Bitcoins is 120 million, billion times harder though.)
David Schwartz
CC BY-SA 3.0
2011-11-29T12:34:07.930Z
2011-11-29T12:34:07.930Z
Meni Rosenfeld
<p>Seeing as the topic of generating address conflicts comes up every now and then, I am wondering if someone looked into the problem a bit further.</p>

<p>Has anyone measured the speed at which Bitcoin addresses can be generated (mainly with some efficient languages, not javascript)? Are there programs akin to GPU miners that instead of generating hashes would generate addresses?</p>

CC BY-SA 3.0
2011-11-29T16:44:47.953Z
Surely it's not just the speed of generating that's interesting. You need to consider the time it takes to look up whether you have a collision, assuming that's the point of generating addresses as fast as possible.
Julian Noble
CC BY-SA 3.0
2011-11-29T19:26:42.167Z
@JulianNoble: Presumably you'll scan the blockchain in advance and compile a list of addresses you'd like to usurp. You put these in a set data structure (maybe a probabilistic one like Bloom filter) and check against it any address you generate. Then the only question is whether this can be done efficiently on a GPU.
Meni Rosenfeld
<address><gpu><vanity-address>
How fast can one generate Bitcoin addresses?
ThePiachu
# How fast can one generate Bitcoin addresses?

(Asked by: username_0 on 2011-11-29)

Seeing as the topic of generating address conflicts comes up every now and then, I am wondering if someone looked into the problem a bit further.

Has anyone measured the speed at which Bitcoin addresses can be generated (mainly with some efficient languages, not javascript)? Are there programs akin to GPU miners that instead of generating hashes would generate addresses?

**Tags:** address, gpu, vanity-address

> **Comments:**
> **username_1**: Surely it's not just the speed of generating that's interesting. You need to consider the time it takes to look up whether you have a collision, assuming that's the point of generating addresses as fast as possible.  
> **username_2**: @username_1: Presumably you'll scan the blockchain in advance and compile a list of addresses you'd like to usurp. You put these in a set data structure (maybe a probabilistic one like Bloom filter) and check against it any address you generate. Then the only question is whether this can be done efficiently on a GPU.  

---

## 1 answers

### Answer by username_2 on 2011-11-29. Score: 7 | Accepted answer

[VanityGen](https://bitcointalk.org/index.php?topic=25804.0) uses the GPU to generate addresses until a desired match is found. On my 5870 it does about 27 million addresses per second.

> **Comments:**
> **username_3**: So about 1.4 billion years to find two keys with the same address. That would allow you to have an address whose coins you could claim with two different keys, which would do no harm whatsoever.  
> **username_0**: @username_3 Add Moore's law to it and we end up at around 45 years (1.4billion ~ 2^30, 30 doublings at the rate of 1.5 years each).  
> **username_3**: Yep. It's quite possible that within 40 years or so, someone will have two private keys that can each claim Bitcoins sent to the same address. (The challenge of claiming anyone else's Bitcoins is 120 million, billion times harder though.)  

---

