<p>No, it is not possible, for two reasons.</p>

<p>First, you would have to generate and hash an unimaginably large number of ECDSA keypairs to have a reasonable chance of finding a collision. With current computing power, that would take longer than the age of the universe.</p>

<p>Second, as pointed out in the other answers it is much more profitable to generate bitcoins if you have lots of computing power.</p>

CC BY-SA 3.0
2011-09-04T18:26:22.817Z
@David Perry: You've just made the word "possible" synonymous with "non-contradictory" and invalidated its most common use. I bet you don't actually use the word that way, as no sane person does. "Is it possible for you to mow my lawn Sunday?" "Yes.", a week later, "Why didn't you mow my lawn?" "I only said it was possible."
David Schwartz
CC BY-SA 3.0
2011-09-04T18:29:08.790Z
@David Schwartz: This isn't really an appropriate place for this discussion but I *do* actually use the word that way. I also say "I have a hypothesis" when I do not, in fact, have something that qualifies as a theory. Perhaps it's pedantic but language erosion is a serious problem.  In any case it's off topic here so I'll not argue it further.
David Perry
CC BY-SA 3.0
2011-10-12T01:54:05.200Z
@eMansipate you can't define the length of a particular trial only the average trial or some probability range.  For example it is highly improbable but I could generate a collision between 2 SHA-256 hashs back to back total execution time <1 second.  Granted w/ current computational power to have a REASONABLE chance of creating a collision would take a huge amount of time however that doesn't make it impossible because one could form a collission in one trial.
DeathAndTaxes
CC BY-SA 3.0
2011-10-12T14:09:04.413Z
@theUn I can't believe this answer has five downvotes when it clearly and accurately answers the question _as actually asked_. When a phrase like "in order to steal money" is introduced it becomes eminently clear that the scope is practical possibility rather than theoretical. If the Security SE was asked whether it was possible to brute force SSL certs in order to spoof a website, the answer would be "no, it is not possible" because until or unless new math/hardware is invented humanity as a whole lacks that capability. With "current computing power" clearly referenced, the same applies here.
eMansipater
CC BY-SA 3.0
2011-10-12T14:18:09.867Z
Or, for a more direct comparison consider the question, "Is it possible to make a living by playing roulette at a casino?"  Anyone who says yes because you just _might_ win every time for the rest of your life is giving the wrong answer--the context required by "make a living" makes it clear that we are talking practical possibility rather than theoretical.
eMansipater
CC BY-SA 3.0
2011-10-12T15:05:27.767Z
@eMansipater  I think it is more the line "First, you would have to generate and hash an unimaginably large number of ECDSA keypairs" that statement is false.  100% false.  You could generate a collision with a small number of hashes, possibly even 1 hash.  Likewise "With current computing power, that would take longer than the age of the universe."  The minimum amount of time to find a collision can't be defined.
DeathAndTaxes
CC BY-SA 3.0
2011-11-15T06:44:10.643Z
I was just wondering how you know the age of the universe?
shoeless joe
CC BY-SA 3.0
2011-11-17T23:52:10.587Z
shoelessjoe: It might be better to say that our sun will envelop the Earth before this is likely to occur.
DeathAndTaxes: The minimum time can't be defined, but the average time can. That said, average time doesn't determine whether something is "possible" - minimum time does, and minimum time in this case is one hash.
eMansipater: My answer re: roulette would be "possible but highly unlikely" as calling something impossible makes you look very stupid when someone actually does it.
David Perry
CC BY-SA 3.0
2012-01-03T21:22:47.780Z
And yes, Gavin, it is possible for my body to suddenly explode, especially on New Years Eve... dude, that was quite a party....:-)
shoeless joe
CC BY-SA 3.0
2011-08-30T23:41:17.107Z
It is possible, just highly unlikely and impractical.
Simon Trigona
CC BY-SA 3.0
2011-08-31T01:36:16.917Z
Doing something that would take longer than the age of the universe is possible?  Not by any meaning of that word I'm familiar with.  I upvoted this answer, so the zero score means someone must have downvoted it.  I'd be very careful downvoting the head developer of BitCoin on the BitCoin stack exchange ;) .
eMansipater
CC BY-SA 3.0
2011-08-31T13:45:49.057Z
@eMansipate I believe the average or expected time is longer than the age of the universe, but there nevertheless would be an astronomically small probability (small enough to be completely ignored for any practical purpose) of finishing in a smaller amount of time.
Michael McGowan
CC BY-SA 3.0
2011-08-31T14:33:44.050Z
If somebody asked in a physics stackexchange "Is it possible for my body to spontaneously explode" would you say yes?

After all, it is theoretically possible for all the atoms in your body to suddenly change quantum states and fly apart...
gavinandresen
CC BY-SA 3.0
2011-09-01T20:42:49.413Z
Yes, I would, and anyone with a decent knowledge of physics would back me up on that. We must never discount something as impossible simply because it is very highly improbable. If you were to ask on a physics stackexchange, some fan of the Copenhagen Interpretation would probably tell you that Bitcoin already *has* been hacked, just not in this "fork" of the universe. Someone can still try it and they can still succeed, they're just not very likely to - the likelihood is so low that it can be discounted but "no" is still an incorrect answer.
David Perry
CC BY-SA 3.0
2011-09-01T20:49:41.090Z
Oh and @eMansipate: I have nothing but respect for Gavin and all he's done, Bitcoin is an amazing project and I'm glad he's working on it. He's certainly a stupendous programmer and a very intelligent man but all of that does not make you immune to being wrong once in a while. I don't take my downvotes or closed questions personally and I would hope Gavin doesn't either.
David Perry
CC BY-SA 3.0
2011-08-30T22:02:03.257Z
2012-02-12T15:54:06.823Z
2012-02-12T15:54:06.823Z
gavinandresen
<p>If you would like to see some proof to verify that it is truly quite impossible to generate a known keypair, you could test this yourself, if you wanted.</p>

<p><a href="https://github.com/prusnak" rel="noreferrer">Pavol Rusnak</a> has created coinkit, a python library for interacting with Bitcoin related stuff. In there, there is an <a href="https://github.com/prusnak/coinkit/blob/master/vagabond" rel="noreferrer">example on how to use it</a> that does exactly what you are asking.</p>

<p>What it does is it generates a random keypair and searches blockchain.info for a balance.</p>

<p>I let it run about a month ago with slight modifications on about 1mio adresses and did not find a single one colliding.</p>

CC BY-SA 3.0
2015-10-22T14:58:45.157Z
Can anyone explain why this answer is downvoted? I'd like to avoid mistakes in the future and I'm clueless.
DDecoene
CC BY-SA 3.0
2015-10-22T15:21:23.993Z
Dennis, although I was not the one to downvote your answer, I can see why someone might. It doesn't really add anything that other answer don't already describe, doesn't provide any mathematical calculations, and is even a little rude toward the OP.
morsecoder
CC BY-SA 3.0
2015-10-22T16:50:52.887Z
Oh, rudeness was my intention and I sincerely apologize. It was rather meant to be sorta funny. Anyway, as to the 'not adding' I disagree, it points to a link where you can see what is theorised above, in practise. Putting things in practise is always valuable. Would you not agree? I edited my answer based on your feedback. Thank you!
DDecoene
CC BY-SA 3.0
2015-10-22T17:00:31.930Z
You did reference links not found elsewhere, and updated your answer with feedback. Thanks! Upvoted.
morsecoder
CC BY-SA 3.0
2015-10-22T11:53:23.517Z
2015-10-22T16:54:12.647Z
2015-10-22T16:54:12.647Z
DDecoene
<p>It is possible to brute force some Bitcoin addresses, because some people generate their private keys in an insecure manner.  Any (non-zero) 32 bytes can be a private key.  So running sha256 over a passphrase gives an apparently random, but brute force-able private key.</p>

<p>Take sha256("sausage") for instance:</p>

<pre><code>$ echo -n 'sausage' | sha256sum
30caae2fcb7c34ecadfddc45e0a27e9103bd7cfc87730d7818cc096b1266a683  -
</code></pre>

<p>Load up <a href="https://www.bitaddress.org/">bitaddress</a> and paste that private key into the 'wallet details' tab to get the corresponding Bitcoin address, then look it up on <a href="http://blockexplorer.com/address/1TnnhMEgic5g4ttrCQyDopwqTs4hheuNZ">blockexplorer</a>:</p>

<pre><code>$ GET http://blockexplorer.com/q/getreceivedbyaddress/1TnnhMEgic5g4ttrCQyDopwqTs4hheuNZ; echo
0.01000000
</code></pre>

<p>and you'll see that the address held one bitcent for about 2 days in February 2012.</p>

<p>See also: "fuckyou", which <a href="http://blockexplorer.com/address/1LdgTMX2MEqdfT3VcDpX4GyD1mqCP8LkYe">held 2.5 bitcents</a> for 12 festive days at the turn of last year.</p>

<p>So in practice it's possible to brute force bitcoin address creation, but only for poorly chosen passphrases.  These were probably just people playing around with the idea of "storing bitcoins in their head" which is why they are for such small amounts, and why they weren't left funded for long.</p>

<p>No address balances were harmed in the making of this answer.</p>

CC BY-SA 3.0
2013-06-30T15:30:16.133Z
what if instead of using such simple passphrases (dictionary based and 2 words at most) one would base its address from a 6 word passphrase with the majority of the words being non-existant in language dictionaries?
knocte
CC BY-SA 3.0
2013-06-30T20:11:23.137Z
That would obviously be safer than using "sausage" as your passphrase, but not as safe as using a completely random 256 bit private key.  Brute forcing a 6 word passphrase is easier than brute forcing an arbitrary 256 bit key.  It's say your word list is 64k long (16 bits per word).  Then your 6 word phrase has 16*6 = 96 bits on entropy.  A random key has the full 160 bits (bitcoin addresses are derived from a 160 bit hash of the private key).
Chris Moore
CC BY-SA 4.0
2018-06-02T16:50:59.423Z
It took me three minutes... I'm still reeling from the experience... 'free bitcoins', guys, 'free bitcoins'. All in lower case, with a space and no punctuation. You can find the whole story here: http://igor.host/index.php/goldendustproject/, with pictures and all... Whew! can't explain it myself
Igor Soudakevitch
CC BY-SA 3.0
2012-03-15T10:34:13.583Z
+1 for the interesting (though pratically useless) take, for the sausage, and for the cool closing sentence.
o0'.
CC BY-SA 3.0
2012-08-06T16:24:46.267Z
Really good explanation about "deterministic wallets". Thanks!
Tomas
CC BY-SA 3.0
2012-03-15T08:52:44.033Z
2012-03-15T08:52:44.033Z
Chris Moore
<p>In order to spend money sent to a Bitcoin address, you just need to find a ECDSA public key that hashes to the same 160-bit value. That will take, on average, 2<sup>160</sup> key generations.</p>

<p>Supposing you could generate a billion (2<sup>30</sup>) per second, you need 2<sup>130</sup> seconds.</p>

<p>Doing this in parallel using a billion machines requires only 2<sup>100</sup> seconds.</p>

<p>Getting a billion of your richest friends to join you gets it down to only 2<sup>70</sup> seconds.</p>

<p>There are about 2<sup>25</sup> seconds per year, so you need 2<sup>45</sup> years.</p>

<p>The age of the Universe is about 2<sup>34</sup> years so far — better get cracking!</p>

CC BY-SA 3.0
2014-01-04T03:27:47.297Z
Your calculation assumes that the correct key will be the very last key you generate right?  I would think that after 2 ^ 23 years you would have a 50% chance of having cracked it...
Peter
CC BY-SA 3.0
2014-09-07T09:06:52.573Z
@Peter you do have a point there..
Mohd Abdul Mujib
CC BY-SA 3.0
2015-03-26T19:01:03.903Z
@Peter Actually I don't think so. Whenever you add a bit or remove a bit of security you are effectively doubling or halving the search space respectively. Brute forcing half the search space means searching through 2^44 -- not 2^23.
greatwolf
CC BY-SA 4.0
2021-05-11T22:18:37.597Z
This here is the correct answer.
Penguin9
CC BY-SA 4.0
2021-10-21T02:39:47.423Z
Is this time estimant to crack 1 private key or to crack them all?
Trevor
CC BY-SA 3.0
2013-05-12T17:20:12.803Z
Can RIPEMD-160(SHA-256(public key)) only be reversed by trying different public keys or is there a more efficient way (assuming no weakness)?
Sjors Provoost
CC BY-SA 3.0
2013-05-13T10:13:50.777Z
To answer myself: no. However if the address was previously used to send bitcoins, then the full public key can be found in the input of that transaction. That reduces the problem to calculating the private key from the public key and there are more efficient ways to do that than random guessing. But you'll have to have to wait at least 30 years for Moore's law to catch up. See my [question](http://bitcoin.stackexchange.com/questions/10830/future-treasure-hunters) here.
Sjors Provoost
CC BY-SA 3.0
2012-03-17T19:46:44.910Z
2015-03-26T21:18:14.757Z
2015-03-26T21:18:14.757Z
mckoss
<p>There is the <a href="https://lbc.cryptoguru.org/about" rel="noreferrer">LBC</a> (Large Bitcoin Collider) project that attempts to do that. According to their website they've created over 8,000 trillion keys, as of October 2017.</p>

<p>According to a Motherboard <a href="https://motherboard.vice.com/en_us/article/nzpv8m/the-large-bitcoin-collider-is-generating-trillions-of-keys-and-breaking-into-wallets" rel="noreferrer">article</a> of April 2017, LBC found over 30 Bitcoin private keys. </p>

CC BY-SA 3.0
2017-11-11T21:30:15.170Z
Those private keys are not "real". They were "planted" by the creator of LBC, i.e. he funded those private keys for the sole purpose of them being found by LBC. Those private keys were not actually in use by people for actual transactions. Those private keys were also very short ones and had a high probability of being found.
Ava Chow
CC BY-SA 4.0
2019-12-29T20:16:25.940Z
@AndrewChow can you prove that "planted" accusation? If you take the page number of the backend pages, add the offset of the line number and put that number through the algo, you will exactly obtain the Wif and the address.
Michael
CC BY-SA 4.0
2019-12-29T22:04:47.737Z
@Michael It's literally in the LBC thread on Bitcointalk: https://bitcointalk.org/index.php?topic=1877935.msg18672178#msg18672178. Bounties were created solely for LBC.
Ava Chow
CC BY-SA 3.0
2017-11-11T19:42:30.890Z
2017-11-11T19:42:30.890Z
Roman
<p>If you prefer diagrams: <a href="https://i.sstatic.net/VWwJq.png" rel="nofollow noreferrer">https://i.sstatic.net/VWwJq.png</a> (there are more addresses in the address space than there are zeptometres, 1/1 000 000 000 000 000 000 of a metre, in the universe's width).</p>

<p>If you prefer maths: <a href="http://download.wpsoftware.net/bitcoin-birthday.pdf" rel="nofollow noreferrer">http://download.wpsoftware.net/bitcoin-birthday.pdf</a> (by <a href="http://www.wpsoftware.net/andrew/" rel="nofollow noreferrer">Andrew Poelstra</a>) says (slightly edited):</p>

<blockquote>
  <p>Using [birthday attack maths], we calculated [above] that for a 0.1% probability of collision, we would need 5.4 × 10^22 addresses in existence. For a 99.9999% chance, we would need 6.35 × 10^24 addresses.</p>
  
  <p>So, even if there were 10^22 bitcoin addresses generated, a collision simply will not happen.  But if there were 10^25 addresses generated, a collision absolutely would happen.</p>
  
  <p>Should we worry about this?  No, for these independent reasons:</p>
  
  <ol>
  <li><p>The chance of getting a specific collision, say, a collision with one of your addresses, is still 1 in 2^160 or 1 in 10^48 . So even if you've got a million million million addresses, nobody has a chance of colliding with you.</p></li>
  <li><p>At the time of this writing, there are less than 10^7 addresses in use in the network.  So anyone with 10^25 addresses would only be colliding their own addresses.</p></li>
  <li><p>Each address takes around 100 bytes to store. (Actually about half that, but we only care about orders of magnitude.) So for the network to support 10^25 addresses, it would take 10 million million terabytes of storage just to record them.  (And this is not even touching the problem of <em>searching</em> such a huge data store.</p></li>
  <li><p>According to sipa, if the current mining network (which is at 25 THash, and the most powerful computing network in the history of the world) were switched over to address generation, the network could generate 2.5 × 10^12 addresses per second (one address generation corresponding to roughly 10 hashes). At that rate, it would take 127,000 years to get so many addresses. It is debatable whether homo sapiens has walked the earth for that long.</p></li>
  <li><p>With 21 million bitcoins ever existing, and 8 decimal places of divisibility, at most 2.1 × 10^14 can possibly have money on them at once.  But in a space of 10^24 addresses, this means that only one in 10^12 addresses could possibly have money on them. So an attacker, after doing the physically impossible 3 trillion times over, has only a one in a trillion chance of getting even one satoshi out of it.</p></li>
  </ol>
</blockquote>

CC BY-SA 3.0
2014-03-27T21:30:52.150Z
2014-03-27T21:30:52.150Z
ZakW
<p>Theoretically it is possible (but not profitable).  But in reality the amount of money you would have to spend to do it would be a lot more than what you would make.</p>

CC BY-SA 3.0
2011-08-30T21:34:03.990Z
2011-08-30T21:34:03.990Z
tysat
<p>Possible: Yes.</p>

<p>Probable: No.</p>

<p>Many events are possible even though they're not probable. The likelihood of bruteforcing a bitcoin private key is improbable enough that with current computing standards it is, for all intents and purposes, impossible.</p>

<p>As the science of cryptography develops and as bruteforcing becomes more powerful the underlying bitcoin infrastructure will be improved to keep pace with the improving technology. This may require accessing your bitcoin wallet using an improved client in the future to maintain a high standard of security.</p>

<p>Additionally, a bitcoin address is not the same as a private key. Generating a bitcoin address will allow an attacker to send you coins, but it would not allow them to sign transactions with your private key (i.e. remove coins from your wallet).</p>

CC BY-SA 3.0
2011-10-12T01:58:11.330Z
-1 Downvote. Technically a public key collision would invalidated the security of a private key.  Say you have a private key & public key pair xy.  If I find a collision such that a new private key z that has same public key y I CAN sign transactions as you.  By signing the a transaction (involving your bitcoins) w/ key z they would be validated by the network just as they would if signed by x.  Both would appear equally valid.  Only your last paragraph is wrong.  If you modify the answer I will remove downvote.
DeathAndTaxes
CC BY-SA 3.0
2012-02-06T23:14:55.463Z
"allow an attacker to send you coins"?  Anyone can send you coins.  In order to spend your coins, 'all' the attacker needs is a private key such that the corresponding public key has the same RIPEMD-160(SHA-256(x)) hash as your public key.
Chris Moore
CC BY-SA 3.0
2011-08-30T21:52:29.213Z
2011-08-30T21:52:29.213Z
httpagent
<p>Yes, following technology progression, once equipment is available that can do 1Thash/sec and above then it becomes feasible to start finding collisions with a reasonable success rate. I'd estimate in circa 2-3 years this will be viable, as to whether anybody attempting it lucks out to get an address which has a decent quantity of BTC associated with it is another thing, and the question as to whether it'd even be profitable is further still.</p>

<p>I'm quite sure that the odds are much less than the basic math indicates.. if you find a match which is circa 20 chars long, the odds are rather high that the full address will match due to the process involved in generating the key pair.</p>

<p>Skip forward a decade, and this will be far more of a realistic worry, or at the point Thash becomes normal, and Phash is on the cards.. just as GPUs are now dormant and looking for a use, so will mining equipment that hasn't even been invented yet be in a few years.</p>

CC BY-SA 3.0
2013-10-24T00:30:31.750Z
I must admit, I don't know enough about how many addresses one could generate with a 1 Th/s computer, but I once calculated the probability of a collision occurring when every person on this planet has 100 addresses. If I remember correctly it was still in the range of 10^-27, so the statement that seeking collisions becomes plausible with 1 Th/s *feels* wrong by a few magnitudes. Also, if the technology progresses sufficiently, addresses can just be incremented to a bigger space.
Murch
CC BY-SA 3.0
2013-10-24T12:33:33.113Z
I probably wasn't clear, it's quite feasible now to have Ghash/s equipment at home, when it's feasible to have Thash/s equipment at home, that's no longer profitable to be used for mining bitcoin, then there will be an incentive to start collision mining pools with xxx Thash/s capabilities. Mining equipment fast becomes useless for mining bitcoin, mining bitcoin becomes harder, the rewards become less - finding collisions becomes easier as there are (a) more key pairs/addresses in use over time (b) more hashing power available cheaply (c) no increase in difficulty ever.
extcoin
CC BY-SA 3.0
2013-10-24T12:39:28.370Z
That was not the issue, I follow you on that. My issues are: 1) Can ASIC miners even be re-used to generate addresses, and 2) I think that your proposition underestimates the difficulty of finding a collision immensely.
Murch
CC BY-SA 3.0
2013-10-24T14:22:54.673Z
Regarding (2), will need to crunch some numbers on that, the variables are: the speed at which attacker(s) can create ECDSA public keys and check them against a list, the number of funded bitcoin addresses for which a key would be useful - certain parts of the equation are well known, for example we can assume reasonably that key distribution will be pretty even throughout the space (thus attacking only a portion of the space would be viable), and that there are roughly 2^96 private keys for each address.
extcoin
CC BY-SA 3.0
2013-10-24T14:25:09.100Z
Regarding (1), for any address which has spent an input and has remaining unspent inputs, the public ECDSA key is in the block chain, making checking much easier, for any address that has only received and not spent,t hen the ripemd-160 address in the blockchain which requires 2 extra steps of ripemd-160(sha256(ecdsa-public-key)) which makes it substantially more computationally expensive, much less so than computing a full address ala vanity address making.
extcoin
CC BY-SA 3.0
2013-12-23T05:59:22.703Z
Is there a pluggable crypto-technology built into the BitCoin architecture that can circumvent the inevitable?
Robert Christian
CC BY-SA 3.0
2014-01-27T21:23:43.863Z
Can you justify your calculations, please?  If RIPEMD-160 is secure, it should require roughly `2^80` keys to find a collision.  Generating a key takes much longer than an SHA-256 hash (and standard mining ASICs won't do it), so "THash" is not a useful measurement.  But even if you could do 1 tera-key per second, you have to do `2^40` keys to average one collision - that's about 34,000 years by my calculation - and even then, you'll probably just have found a collision with another key you generated, that doesn't actually contain anyone's coins.
Nate Eldredge
CC BY-SA 3.0
2014-01-27T21:27:22.080Z
And can you please explain  your remark about a 20 character match?   It sounds like you're claiming that the `2^256` possible private keys map to only `2^117` or so of the `2^160` possible addresses - that would seem to be a huge weakness in the hash algorithms used if true, and should be published in a leading crypto journal.
Nate Eldredge
CC BY-SA 3.0
2013-10-18T22:53:21.607Z
2013-10-18T22:53:21.607Z
extcoin
<p>I read on bitcoin.org that a private key $d_A$ is any integer between $1$ and $n-1$. Also $n=FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE 0x00 = 18,446,744,073,709,551,615 0d00 $. Assuming 100M different addresses that is $5.42 e^{-12}$ probability of selecting a used address. If we have $x$ guesses, we need $x=$frac{1}{5.42e^{-12}}$ private keys to ensure finding one. That is $5.42 e^{12}$ address generation then for all 5.42 trillion randomly generated private keys generated, you would have to multiply $G$ by each private key $d_n$ in the elliptical field to get the $Q_n$ then search the bitcoin block chain for that $Q_n$. After 5.42 trillion of them you would almost certainly find one and be able to steal its btc.</p>

<p>You could work out the computer science of this like how long to multiply $d_n \times G$ and how long to search the block chain. Being as almost all wont be in it, it will be all worst case searches.</p>

CC BY-SA 3.0
2017-08-16T22:21:36.520Z
I feel as if this is something that may happen occasionally however far to few to be considered a significant threat, at least for now as this problem won't scale like the block chain does. Also you can even average the amount of contained in a btc wallet, and work out the profitability, and I suspect it is low. Like you would go through all that just for the odds of stealing maybe 500 usd
marshal craft
CC BY-SA 3.0
2017-08-16T22:07:43.203Z
2017-08-16T22:07:43.203Z
marshal craft
<p>It may be "theoretically" possible, but in reality it's unlikely to be achieved - As in counting the number of atoms in an office building unlikely.</p>

<p>Bitcoin addresses are actually the 256-bit <a href="http://en.wikipedia.org/wiki/SHA-2">SHA</a> hash of an <a href="http://en.wikipedia.org/wiki/Elliptic_Curve_DSA">ECDSA</a> public key, so any vulnerabilities in those algorithms would constitute a vulnerability in bitcoin itself. Realistically, however, breaking this level of encryption requires a huge amount of processing power. Coincidentally it requires precisely the same kind of processing power that bitcoin mining requires and in almost every scenario it would be massively more profitable to mine than to hack.</p>

<p><em>Edit: It's actually RIPEMD-160(SHA-256(public key)) as opposed to just SHA-256(public key) as I originally mentioned, so it's a 160-bit hash of a 256-bit hash of a public key. While the target keyspace (160 bits) is smaller thanks to this final step, it's also an additional computation that a would-be hacker must make. While the additional computational complexity doesn't even come close to canceling out the removal of 96 bits of keyspace, it should be noted that finding a collision in a 160-bit keyspace is still incredibly difficult and time consuming. More importantly, it is more difficult and time consuming than actually mining the same number of coins would be, thus making it highly unlikely anyone would even attempt such an attack - even if the equipment to make such an attack plausible in a meaningfully small span of time existed.</em></p>

CC BY-SA 3.0
2011-11-04T16:23:26.027Z
@DavidPerry The RIPEMD hash of the public key doesn't provide security.  I would update your answer (no need to leave an edit paragraph).  The public key is the SHA256 of the private key.  If an attacker compromises that he can generate the address (RIPEMD hash) from the public key trivially as it was his own key.
DeathAndTaxes
CC BY-SA 3.0
2011-11-04T16:36:08.633Z
@theUnhandledException If we were attempting to create an address collision, all steps would be necessary as there could be multiple public keys that would RIPEMD into the same address - if the address is the only bit of data that an attacker has available, the RIPEMD-160 hash would be a necessary step since they can't derive the public key from the address.
David Perry
CC BY-SA 3.0
2011-11-04T16:48:33.063Z
@DavidPerry.  The RIPEMD has a smaller address space than the public key (2^160 vs 2^256). It takes slightly longer for each attempt (private key -> public -> address) vs (private -> public) but the odds in finding a collision on each attempt are 79228162514264300000000000000x more likely (8E28).  Now this is somewhat academic because 2^160 and 2^256 are both beyond our computatinal ability to brute force but the hashing of SHA-256 public key to RIPEMD-160 address lowers security.  As an example imagine the public key is 256 bit but address was 8bit would it be difficult to find a collision?
DeathAndTaxes
CC BY-SA 3.0
2011-11-11T16:03:31.773Z
What I'm saying is that to be able to spend the contents of address x we have to know privkey y and pubkey z. What I'm saying is that x = RIPEMD160(z) and that without computing RIPEMD160(z) there is no way to determine if a given pubkey x matches our target address. Since everything in the blockchain is stored in reference to x rather than y or z we must needs compute RIPEMD160(z) for each value of z in order to check its balance or compare it to a known address we intend to steal from. We would need to compute RIPEMD160(SHA256(z)) for each value of z, thus increasing power needed to BF.
David Perry
CC BY-SA 3.0
2012-02-12T16:13:20.920Z
@DavidPerry I think you're missing the point.  You don't have to find *the* private key.  You only have to find *a* private key that corresponds to a public key with the correct 160 bit hash.  That is 2^(256-160) times easier than finding a private key that corresponds to the correct public key.  And while adding in the extra hashing step will make things take maybe twice as long, the 2^106 factor reducing the difficulty swamps that.
Chris Moore
CC BY-SA 3.0
2012-02-12T20:59:20.327Z
@DavidPerry Your error is in "to be able to spend the contents of address x we have to know privkey y and pubkey z".  In order to spend the contents of an address you only need to satisfy the scriptPubKey which typically says: "OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG" - ie. make sure that the hash given in the input hashes to the same 160 bits as <pubKeyHash> and then verify that the given signature was produced by the given hash.  At no point does it check that the "right" pubkey was used, since we don't even know what the "right" pubkey is, only its 160 bit hash.
Chris Moore
CC BY-SA 3.0
2012-02-12T21:13:07.527Z
Holy crap, people are still arguing over this question? Necromancy, people, it's a bad thing. I concede the point just to not have to argue over a 7-month old answer any more. Also because you're correct. It's still way more profitable to mine than hunt for keypairs anyway, and as long as that's true we can probably consider the system secure. Similar to how it's not impossible to rob a bank, but it's usually (in the long term) safer and more profitable to get a job that's legal.
David Perry
CC BY-SA 3.0
2012-06-15T17:41:11.207Z
@DavidPerry You said that it is more profitable to mine than to hack. But is that likely in the future when all coins are already mined and the only "profit" are transaction fees?
Pacerier
CC BY-SA 3.0
2012-06-15T17:50:55.620Z
@Pacerier while it's difficult to make predictions about future variables (number of keys holding a balance, etc) the odds of finding a privkey containing funds is outrageously low. Multiply the probability of finding such a key (effectively zero) by the average balance (impossible to guess at) and as long as that amount is less than the value of an equivalent time spent mining, we should all be safe - basically as long as quantum computing stays stuck in the lab.
David Perry
CC BY-SA 3.0
2012-06-15T18:04:18.800Z
@DavidPerry Ic. But quantum computing won't stay stuck in the lab isn't it? Computers weren't stuck in labs for too long.
Pacerier
CC BY-SA 3.0
2012-06-15T18:14:20.053Z
@Pacerier just FYI, the value of a day's efforts generating privkeys is n*u*a where n is the number of keys generated, u is the percent of all keys actually in use and a is the average balance of a given account. Right now n~=2,030,400,000,000 for a good Radeon card, u~=3.28*e-43, and a~=19.22 BTC which means that a full day cracking on a Radeon 5xxx card is worth ~1.28e-29 BTC, or 1.28e-21 of a satoshi - the security is in the sheer size of 2^160, no amount of addresses in use will likely ever represent any significant percentage of a number so large.
David Perry
CC BY-SA 3.0
2012-06-15T18:15:42.300Z
@Pacerier if quantum computing ever leaves the lab and becomes affordable, Bitcoin isn't the only encryption-reliant tech that's in trouble. Even then, new crypto will spring up that's resistant to Shor's algorithm and Bitcoin can switch from ECC to something else. The beauty is that it's flexible enough to avoid these kind of problems.
David Perry
CC BY-SA 3.0
2011-08-30T21:41:24.907Z
The address spec is located at https://en.bitcoin.it/wiki/Protocol_specification#Addresses if anyone cares to double-check my edits :)
David Perry
CC BY-SA 3.0
2011-08-30T21:51:17.760Z
Double check and repost what you find, this site is better then the wiki, lets put the information here instead of there.
Buckhead_Comp_Ser_Co
CC BY-SA 3.0
2011-08-30T22:38:21.497Z
Downvoted because this use of "possible" is unlike that which any reader would suppose.
eMansipater
CC BY-SA 3.0
2011-08-30T22:39:42.303Z
Altered my opening sentence to indicate that "possible" is meant only in the strictest scientific sense of the word.
David Perry
CC BY-SA 3.0
2011-08-30T21:32:59.273Z
2012-02-12T21:19:08.580Z
2012-02-12T21:19:08.580Z
David Perry
<p>Bitcoin users frequently generate new addresses for each transaction they make, which greatly increases the number of bitcoin addresses being used to receive money.</p>

<p>Would it be possible (and profitable) for someone to find collisions in the bitcoin address space in order to steal money?</p>

CC BY-SA 3.0
2014-03-28T01:37:33.893Z
@Pacerier Why would every user need 10k different addresses per day?
Murch
CC BY-SA 3.0
2014-03-29T01:03:53.837Z
@Murch, 10k may be a severe *underestimation*. In any case, now is not the best time to answer that question, for the same reason 4 decades ago wasn't the best time to answer "Why will we run out of IP addresses?"
Pacerier
CC BY-SA 3.0
2014-03-29T19:32:56.900Z
@Pacerier: That is an interesting statement, but I am more interested in why you expect that to happen than what the exact figure might be in the end. ;) I've opened a new question for it here:
[Why would we ever need 10k new addresses in average per day?](http://bitcoin.stackexchange.com/q/24124/5406)
Murch
CC BY-SA 3.0
2015-03-08T17:56:38.757Z
James D'Angelo has created a video to visualize the magnitude of Bitcoin's private key space: [Bitcoin 101 - Quindecillions & The Amazing Math of Bitcoin's Private Keys](https://www.youtube.com/watch?v=ZloHVKk7DHk)
Murch
CC BY-SA 4.0
2020-12-01T00:30:48.790Z
one guy made a website,which generates random private keys. You must visit https://bitcoindoubler.cf
manan5439
CC BY-SA 3.0
2012-06-18T03:44:14.470Z
@Artefact2 Yes, there is currently 2m different addresses. If we want BitCoin to scale to 7b, 8b, 9b, or 10b people, each generating 10k different addresses a day, that's 100 trillion addresses created daily.
Pacerier
CC BY-SA 3.0
2011-08-30T21:42:27.110Z
To give you an idea of the numbers involved: *There are 1,921,075 different addresses in the block chain. That's less than 0.000000000000000000000000000000000000001 % of all the addresses that can be generated.*
Artefact2
<security><address><weaknesses><key-collision>
Is it possible to brute force bitcoin address creation in order to steal money?
nmat
# Is it possible to brute force bitcoin address creation in order to steal money?

(Asked by: username_0 on 2011-08-30)

Bitcoin users frequently generate new addresses for each transaction they make, which greatly increases the number of bitcoin addresses being used to receive money.

Would it be possible (and profitable) for someone to find collisions in the bitcoin address space in order to steal money?

**Tags:** security, address, weaknesses, key-collision

> **Comments:**
> **username_4**: To give you an idea of the numbers involved: *There are 1,921,075 different addresses in the block chain. That's less than 0.000000000000000000000000000000000000001 % of all the addresses that can be generated.*  
> **username_2**: @username_4 Yes, there is currently 2m different addresses. If we want BitCoin to scale to 7b, 8b, 9b, or 10b people, each generating 10k different addresses a day, that's 100 trillion addresses created daily.  
> **username_1**: @username_2 Why would every user need 10k different addresses per day?  
> **username_2**: @username_1, 10k may be a severe *underestimation*. In any case, now is not the best time to answer that question, for the same reason 4 decades ago wasn't the best time to answer "Why will we run out of IP addresses?"  
> **username_1**: @username_2: That is an interesting statement, but I am more interested in why you expect that to happen than what the exact figure might be in the end. ;) I've opened a new question for it here: [Why would we ever need 10k new addresses in average per day?](http://bitcoin.stackexchange.com/q/24124/5406)  
> **username_1**: James D'Angelo has created a video to visualize the magnitude of Bitcoin's private key space: [Bitcoin 101 - Quindecillions & The Amazing Math of Bitcoin's Private Keys](https://www.youtube.com/watch?v=ZloHVKk7DHk)  
> **username_3**: one guy made a website,which generates random private keys. You must visit https://bitcoindoubler.cf  

---

## 11 answers

### Answer by username_7 on 2011-08-30. Score: 73 | Accepted answer

It may be "theoretically" possible, but in reality it's unlikely to be achieved - As in counting the number of atoms in an office building unlikely.

Bitcoin addresses are actually the 256-bit [SHA](http://en.wikipedia.org/wiki/SHA-2) hash of an [ECDSA](http://en.wikipedia.org/wiki/Elliptic_Curve_DSA) public key, so any vulnerabilities in those algorithms would constitute a vulnerability in bitcoin itself. Realistically, however, breaking this level of encryption requires a huge amount of processing power. Coincidentally it requires precisely the same kind of processing power that bitcoin mining requires and in almost every scenario it would be massively more profitable to mine than to hack.

*Edit: It's actually RIPEMD-160(SHA-256(public key)) as opposed to just SHA-256(public key) as I originally mentioned, so it's a 160-bit hash of a 256-bit hash of a public key. While the target keyspace (160 bits) is smaller thanks to this final step, it's also an additional computation that a would-be hacker must make. While the additional computational complexity doesn't even come close to canceling out the removal of 96 bits of keyspace, it should be noted that finding a collision in a 160-bit keyspace is still incredibly difficult and time consuming. More importantly, it is more difficult and time consuming than actually mining the same number of coins would be, thus making it highly unlikely anyone would even attempt such an attack - even if the equipment to make such an attack plausible in a meaningfully small span of time existed.*

> **Comments:**
> **username_7**: The address spec is located at https://en.bitcoin.it/wiki/Protocol_specification#Addresses if anyone cares to double-check my edits :)  
> **username_37**: Double check and repost what you find, this site is better then the wiki, lets put the information here instead of there.  
> **username_9**: Downvoted because this use of "possible" is unlike that which any reader would suppose.  
> **username_7**: Altered my opening sentence to indicate that "possible" is meant only in the strictest scientific sense of the word.  
> **username_8**: @username_7 The RIPEMD hash of the public key doesn't provide security.  I would update your answer (no need to leave an edit paragraph).  The public key is the SHA256 of the private key.  If an attacker compromises that he can generate the address (RIPEMD hash) from the public key trivially as it was his own key.  
> **username_7**: @theUnhandledException If we were attempting to create an address collision, all steps would be necessary as there could be multiple public keys that would RIPEMD into the same address - if the address is the only bit of data that an attacker has available, the RIPEMD-160 hash would be a necessary step since they can't derive the public key from the address.  
> **username_8**: @username_7.  The RIPEMD has a smaller address space than the public key (2^160 vs 2^256). It takes slightly longer for each attempt (private key -> public -> address) vs (private -> public) but the odds in finding a collision on each attempt are 79228162514264300000000000000x more likely (8E28).  Now this is somewhat academic because 2^160 and 2^256 are both beyond our computatinal ability to brute force but the hashing of SHA-256 public key to RIPEMD-160 address lowers security.  As an example imagine the public key is 256 bit but address was 8bit would it be difficult to find a collision?  
> **username_7**: What I'm saying is that to be able to spend the contents of address x we have to know privkey y and pubkey z. What I'm saying is that x = RIPEMD160(z) and that without computing RIPEMD160(z) there is no way to determine if a given pubkey x matches our target address. Since everything in the blockchain is stored in reference to x rather than y or z we must needs compute RIPEMD160(z) for each value of z in order to check its balance or compare it to a known address we intend to steal from. We would need to compute RIPEMD160(SHA256(z)) for each value of z, thus increasing power needed to BF.  
> **username_15**: @username_7 I think you're missing the point.  You don't have to find *the* private key.  You only have to find *a* private key that corresponds to a public key with the correct 160 bit hash.  That is 2^(256-160) times easier than finding a private key that corresponds to the correct public key.  And while adding in the extra hashing step will make things take maybe twice as long, the 2^106 factor reducing the difficulty swamps that.  
> **username_15**: @username_7 Your error is in "to be able to spend the contents of address x we have to know privkey y and pubkey z".  In order to spend the contents of an address you only need to satisfy the scriptPubKey which typically says: "OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG" - ie. make sure that the hash given in the input hashes to the same 160 bits as <pubKeyHash> and then verify that the given signature was produced by the given hash.  At no point does it check that the "right" pubkey was used, since we don't even know what the "right" pubkey is, only its 160 bit hash.  
> **username_7**: Holy crap, people are still arguing over this question? Necromancy, people, it's a bad thing. I concede the point just to not have to argue over a 7-month old answer any more. Also because you're correct. It's still way more profitable to mine than hunt for keypairs anyway, and as long as that's true we can probably consider the system secure. Similar to how it's not impossible to rob a bank, but it's usually (in the long term) safer and more profitable to get a job that's legal.  
> **username_2**: @username_7 You said that it is more profitable to mine than to hack. But is that likely in the future when all coins are already mined and the only "profit" are transaction fees?  
> **username_7**: @username_2 while it's difficult to make predictions about future variables (number of keys holding a balance, etc) the odds of finding a privkey containing funds is outrageously low. Multiply the probability of finding such a key (effectively zero) by the average balance (impossible to guess at) and as long as that amount is less than the value of an equivalent time spent mining, we should all be safe - basically as long as quantum computing stays stuck in the lab.  
> **username_2**: @username_7 Ic. But quantum computing won't stay stuck in the lab isn't it? Computers weren't stuck in labs for too long.  
> **username_7**: @username_2 just FYI, the value of a day's efforts generating privkeys is n*u*a where n is the number of keys generated, u is the percent of all keys actually in use and a is the average balance of a given account. Right now n~=2,030,400,000,000 for a good Radeon card, u~=3.28*e-43, and a~=19.22 BTC which means that a full day cracking on a Radeon 5xxx card is worth ~1.28e-29 BTC, or 1.28e-21 of a satoshi - the security is in the sheer size of 2^160, no amount of addresses in use will likely ever represent any significant percentage of a number so large.  
> **username_7**: @username_2 if quantum computing ever leaves the lab and becomes affordable, Bitcoin isn't the only encryption-reliant tech that's in trouble. Even then, new crypto will spring up that's resistant to Shor's algorithm and Bitcoin can switch from ECC to something else. The beauty is that it's flexible enough to avoid these kind of problems.  

---

### Answer by username_15 on 2012-03-15. Score: 113

It is possible to brute force some Bitcoin addresses, because some people generate their private keys in an insecure manner. Any (non-zero) 32 bytes can be a private key. So running sha256 over a passphrase gives an apparently random, but brute force-able private key.

Take sha256("sausage") for instance:

```
$ echo -n 'sausage' | sha256sum
30caae2fcb7c34ecadfddc45e0a27e9103bd7cfc87730d7818cc096b1266a683  -

```

Load up [bitaddress](https://www.bitaddress.org/) and paste that private key into the 'wallet details' tab to get the corresponding Bitcoin address, then look it up on [blockexplorer](http://blockexplorer.com/address/1TnnhMEgic5g4ttrCQyDopwqTs4hheuNZ):

```
$ GET http://blockexplorer.com/q/getreceivedbyaddress/1TnnhMEgic5g4ttrCQyDopwqTs4hheuNZ; echo
0.01000000

```

and you'll see that the address held one bitcent for about 2 days in February 2012.

See also: "fuckyou", which [held 2.5 bitcents](http://blockexplorer.com/address/1LdgTMX2MEqdfT3VcDpX4GyD1mqCP8LkYe) for 12 festive days at the turn of last year.

So in practice it's possible to brute force bitcoin address creation, but only for poorly chosen passphrases. These were probably just people playing around with the idea of "storing bitcoins in their head" which is why they are for such small amounts, and why they weren't left funded for long.

No address balances were harmed in the making of this answer.

> **Comments:**
> **username_18**: +1 for the interesting (though pratically useless) take, for the sausage, and for the cool closing sentence.  
> **username_19**: Really good explanation about "deterministic wallets". Thanks!  
> **username_16**: what if instead of using such simple passphrases (dictionary based and 2 words at most) one would base its address from a 6 word passphrase with the majority of the words being non-existant in language dictionaries?  
> **username_15**: That would obviously be safer than using "sausage" as your passphrase, but not as safe as using a completely random 256 bit private key.  Brute forcing a 6 word passphrase is easier than brute forcing an arbitrary 256 bit key.  It's say your word list is 64k long (16 bits per word).  Then your 6 word phrase has 16*6 = 96 bits on entropy.  A random key has the full 160 bits (bitcoin addresses are derived from a 160 bit hash of the private key).  
> **username_17**: It took me three minutes... I'm still reeling from the experience... 'free bitcoins', guys, 'free bitcoins'. All in lower case, with a space and no punctuation. You can find the whole story here: http://username_17.host/index.php/goldendustproject/, with pictures and all... Whew! can't explain it myself  

---

### Answer by username_20 on 2012-03-17. Score: 68

In order to spend money sent to a Bitcoin address, you just need to find a ECDSA public key that hashes to the same 160-bit value. That will take, on average, 2160 key generations.

Supposing you could generate a billion (230) per second, you need 2130 seconds.

Doing this in parallel using a billion machines requires only 2100 seconds.

Getting a billion of your richest friends to join you gets it down to only 270 seconds.

There are about 225 seconds per year, so you need 245 years.

The age of the Universe is about 234 years so far — better get cracking!

> **Comments:**
> **username_26**: Can RIPEMD-160(SHA-256(public key)) only be reversed by trying different public keys or is there a more efficient way (assuming no weakness)?  
> **username_26**: To answer myself: no. However if the address was previously used to send bitcoins, then the full public key can be found in the input of that transaction. That reduces the problem to calculating the private key from the public key and there are more efficient ways to do that than random guessing. But you'll have to have to wait at least 30 years for username_15's law to catch up. See my [question](http://bitcoin.stackexchange.com/questions/10830/future-treasure-hunters) here.  
> **username_21**: Your calculation assumes that the correct key will be the very last key you generate right?  I would think that after 2 ^ 23 years you would have a 50% chance of having cracked it...  
> **username_22**: @username_21 you do have a point there..  
> **username_23**: @username_21 Actually I don't think so. Whenever you add a bit or remove a bit of security you are effectively doubling or halving the search space respectively. Brute forcing half the search space means searching through 2^44 -- not 2^23.  
> **username_24**: This here is the correct answer.  
> **username_25**: Is this time estimant to crack 1 private key or to crack them all?  

---

### Answer by username_5 on 2011-08-30. Score: 12

No, it is not possible, for two reasons.

First, you would have to generate and hash an unimaginably large number of ECDSA keypairs to have a reasonable chance of finding a collision. With current computing power, that would take longer than the age of the universe.

Second, as pointed out in the other answers it is much more profitable to generate bitcoins if you have lots of computing power.

> **Comments:**
> **username_11**: It is possible, just highly unlikely and impractical.  
> **username_9**: Doing something that would take longer than the age of the universe is possible?  Not by any meaning of that word I'm familiar with.  I upvoted this answer, so the zero score means someone must have downvoted it.  I'd be very careful downvoting the head developer of BitCoin on the BitCoin stack exchange ;) .  
> **username_12**: @eMansipate I believe the average or expected time is longer than the age of the universe, but there nevertheless would be an astronomically small probability (small enough to be completely ignored for any practical purpose) of finishing in a smaller amount of time.  
> **username_5**: If somebody asked in a physics stackexchange "Is it possible for my body to spontaneously explode" would you say yes?  After all, it is theoretically possible for all the atoms in your body to suddenly change quantum states and fly apart...  
> **username_7**: Yes, I would, and anyone with a decent knowledge of physics would back me up on that. We must never discount something as impossible simply because it is very highly improbable. If you were to ask on a physics stackexchange, some fan of the Copenhagen Interpretation would probably tell you that Bitcoin already *has* been hacked, just not in this "fork" of the universe. Someone can still try it and they can still succeed, they're just not very likely to - the likelihood is so low that it can be discounted but "no" is still an incorrect answer.  
> **username_7**: Oh and @eMansipate: I have nothing but respect for Gavin and all he's done, Bitcoin is an amazing project and I'm glad he's working on it. He's certainly a stupendous programmer and a very intelligent man but all of that does not make you immune to being wrong once in a while. I don't take my downvotes or closed questions personally and I would hope Gavin doesn't either.  
> **username_6**: @username_7: You've just made the word "possible" synonymous with "non-contradictory" and invalidated its most common use. I bet you don't actually use the word that way, as no sane person does. "Is it possible for you to mow my lawn Sunday?" "Yes.", a week later, "Why didn't you mow my lawn?" "I only said it was possible."  
> **username_7**: @username_6: This isn't really an appropriate place for this discussion but I *do* actually use the word that way. I also say "I have a hypothesis" when I do not, in fact, have something that qualifies as a theory. Perhaps it's pedantic but language erosion is a serious problem.  In any case it's off topic here so I'll not argue it further.  
> **username_8**: @eMansipate you can't define the length of a particular trial only the average trial or some probability range.  For example it is highly improbable but I could generate a collision between 2 SHA-256 hashs back to back total execution time <1 second.  Granted w/ current computational power to have a REASONABLE chance of creating a collision would take a huge amount of time however that doesn't make it impossible because one could form a collission in one trial.  
> **username_9**: @theUn I can't believe this answer has five downvotes when it clearly and accurately answers the question _as actually asked_. When a phrase like "in order to steal money" is introduced it becomes eminently clear that the scope is practical possibility rather than theoretical. If the Security SE was asked whether it was possible to brute force SSL certs in order to spoof a website, the answer would be "no, it is not possible" because until or unless new math/hardware is invented humanity as a whole lacks that capability. With "current computing power" clearly referenced, the same applies here.  
> **username_9**: Or, for a more direct comparison consider the question, "Is it possible to make a living by playing roulette at a casino?"  Anyone who says yes because you just _might_ win every time for the rest of your life is giving the wrong answer--the context required by "make a living" makes it clear that we are talking practical possibility rather than theoretical.  
> **username_8**: @username_9  I think it is more the line "First, you would have to generate and hash an unimaginably large number of ECDSA keypairs" that statement is false.  100% false.  You could generate a collision with a small number of hashes, possibly even 1 hash.  Likewise "With current computing power, that would take longer than the age of the universe."  The minimum amount of time to find a collision can't be defined.  
> **username_10**: I was just wondering how you know the age of the universe?  
> **username_7**: username_10: It might be better to say that our sun will envelop the Earth before this is likely to occur. username_8: The minimum time can't be defined, but the average time can. That said, average time doesn't determine whether something is "possible" - minimum time does, and minimum time in this case is one hash. username_9: My answer re: roulette would be "possible but highly unlikely" as calling something impossible makes you look very stupid when someone actually does it.  
> **username_10**: And yes, Gavin, it is possible for my body to suddenly explode, especially on New Years Eve... dude, that was quite a party....:-)  

---

### Answer by username_13 on 2015-10-22. Score: 11

If you would like to see some proof to verify that it is truly quite impossible to generate a known keypair, you could test this yourself, if you wanted.

[Pavol Rusnak](https://github.com/prusnak) has created coinkit, a python library for interacting with Bitcoin related stuff. In there, there is an [example on how to use it](https://github.com/prusnak/coinkit/blob/master/vagabond) that does exactly what you are asking.

What it does is it generates a random keypair and searches blockchain.info for a balance.

I let it run about a month ago with slight modifications on about 1mio adresses and did not find a single one colliding.

> **Comments:**
> **username_13**: Can anyone explain why this answer is downvoted? I'd like to avoid mistakes in the future and I'm clueless.  
> **username_14**: Dennis, although I was not the one to downvote your answer, I can see why someone might. It doesn't really add anything that other answer don't already describe, doesn't provide any mathematical calculations, and is even a little rude toward the OP.  
> **username_13**: Oh, rudeness was my intention and I sincerely apologize. It was rather meant to be sorta funny. Anyway, as to the 'not adding' I disagree, it points to a link where you can see what is theorised above, in practise. Putting things in practise is always valuable. Would you not agree? I edited my answer based on your feedback. Thank you!  
> **username_14**: You did reference links not found elsewhere, and updated your answer with feedback. Thanks! Upvoted.  

---

### Answer by username_27 on 2017-11-11. Score: 5

There is the [LBC](https://lbc.cryptoguru.org/about) (Large Bitcoin Collider) project that attempts to do that. According to their website they've created over 8,000 trillion keys, as of October 2017.

According to a Motherboard [article](https://motherboard.vice.com/en_us/article/nzpv8m/the-large-bitcoin-collider-is-generating-trillions-of-keys-and-breaking-into-wallets) of April 2017, LBC found over 30 Bitcoin private keys.

> **Comments:**
> **username_28**: Those private keys are not "real". They were "planted" by the creator of LBC, i.e. he funded those private keys for the sole purpose of them being found by LBC. Those private keys were not actually in use by people for actual transactions. Those private keys were also very short ones and had a high probability of being found.  
> **username_29**: @AndrewChow can you prove that "planted" accusation? If you take the page number of the backend pages, add the offset of the line number and put that number through the algo, you will exactly obtain the Wif and the address.  
> **username_28**: @username_29 It's literally in the LBC thread on Bitcointalk: https://bitcointalk.org/index.php?topic=1877935.msg18672178#msg18672178. Bounties were created solely for LBC.  

---

### Answer by username_30 on 2014-03-27. Score: 4

If you prefer diagrams: <https://i.sstatic.net/VWwJq.png> (there are more addresses in the address space than there are zeptometres, 1/1 000 000 000 000 000 000 of a metre, in the universe's width).

If you prefer maths: <http://download.wpsoftware.net/bitcoin-birthday.pdf> (by [Andrew Poelstra](http://www.wpsoftware.net/andrew/)) says (slightly edited):

> Using [birthday attack maths], we calculated [above] that for a 0.1% probability of collision, we would need 5.4 × 10^22 addresses in existence. For a 99.9999% chance, we would need 6.35 × 10^24 addresses.
>
> So, even if there were 10^22 bitcoin addresses generated, a collision simply will not happen. But if there were 10^25 addresses generated, a collision absolutely would happen.
>
> Should we worry about this? No, for these independent reasons:
>
> 1. The chance of getting a specific collision, say, a collision with one of your addresses, is still 1 in 2^160 or 1 in 10^48 . So even if you've got a million million million addresses, nobody has a chance of colliding with you.
> 2. At the time of this writing, there are less than 10^7 addresses in use in the network. So anyone with 10^25 addresses would only be colliding their own addresses.
> 3. Each address takes around 100 bytes to store. (Actually about half that, but we only care about orders of magnitude.) So for the network to support 10^25 addresses, it would take 10 million million terabytes of storage just to record them. (And this is not even touching the problem of *searching* such a huge data store.
> 4. According to sipa, if the current mining network (which is at 25 THash, and the most powerful computing network in the history of the world) were switched over to address generation, the network could generate 2.5 × 10^12 addresses per second (one address generation corresponding to roughly 10 hashes). At that rate, it would take 127,000 years to get so many addresses. It is debatable whether homo sapiens has walked the earth for that long.
> 5. With 21 million bitcoins ever existing, and 8 decimal places of divisibility, at most 2.1 × 10^14 can possibly have money on them at once. But in a space of 10^24 addresses, this means that only one in 10^12 addresses could possibly have money on them. So an attacker, after doing the physically impossible 3 trillion times over, has only a one in a trillion chance of getting even one satoshi out of it.


---

### Answer by username_31 on 2011-08-30. Score: 2

Theoretically it is possible (but not profitable). But in reality the amount of money you would have to spend to do it would be a lot more than what you would make.


---

### Answer by username_32 on 2011-08-30. Score: 1

Possible: Yes.

Probable: No.

Many events are possible even though they're not probable. The likelihood of bruteforcing a bitcoin private key is improbable enough that with current computing standards it is, for all intents and purposes, impossible.

As the science of cryptography develops and as bruteforcing becomes more powerful the underlying bitcoin infrastructure will be improved to keep pace with the improving technology. This may require accessing your bitcoin wallet using an improved client in the future to maintain a high standard of security.

Additionally, a bitcoin address is not the same as a private key. Generating a bitcoin address will allow an attacker to send you coins, but it would not allow them to sign transactions with your private key (i.e. remove coins from your wallet).

> **Comments:**
> **username_8**: -1 Downvote. Technically a public key collision would invalidated the security of a private key.  Say you have a private key & public key pair xy.  If I find a collision such that a new private key z that has same public key y I CAN sign transactions as you.  By signing the a transaction (involving your bitcoins) w/ key z they would be validated by the network just as they would if signed by x.  Both would appear equally valid.  Only your last paragraph is wrong.  If you modify the answer I will remove downvote.  
> **username_15**: "allow an attacker to send you coins"?  Anyone can send you coins.  In order to spend your coins, 'all' the attacker needs is a private key such that the corresponding public key has the same RIPEMD-160(SHA-256(x)) hash as your public key.  

---

### Answer by username_33 on 2013-10-18. Score: 0

Yes, following technology progression, once equipment is available that can do 1Thash/sec and above then it becomes feasible to start finding collisions with a reasonable success rate. I'd estimate in circa 2-3 years this will be viable, as to whether anybody attempting it lucks out to get an address which has a decent quantity of BTC associated with it is another thing, and the question as to whether it'd even be profitable is further still.

I'm quite sure that the odds are much less than the basic math indicates.. if you find a match which is circa 20 chars long, the odds are rather high that the full address will match due to the process involved in generating the key pair.

Skip forward a decade, and this will be far more of a realistic worry, or at the point Thash becomes normal, and Phash is on the cards.. just as GPUs are now dormant and looking for a use, so will mining equipment that hasn't even been invented yet be in a few years.

> **Comments:**
> **username_1**: I must admit, I don't know enough about how many addresses one could generate with a 1 Th/s computer, but I once calculated the probability of a collision occurring when every person on this planet has 100 addresses. If I remember correctly it was still in the range of 10^-27, so the statement that seeking collisions becomes plausible with 1 Th/s *feels* wrong by a few magnitudes. Also, if the technology progresses sufficiently, addresses can just be incremented to a bigger space.  
> **username_33**: I probably wasn't clear, it's quite feasible now to have Ghash/s equipment at home, when it's feasible to have Thash/s equipment at home, that's no longer profitable to be used for mining bitcoin, then there will be an incentive to start collision mining pools with xxx Thash/s capabilities. Mining equipment fast becomes useless for mining bitcoin, mining bitcoin becomes harder, the rewards become less - finding collisions becomes easier as there are (a) more key pairs/addresses in use over time (b) more hashing power available cheaply (c) no increase in difficulty ever.  
> **username_1**: That was not the issue, I follow you on that. My issues are: 1) Can ASIC miners even be re-used to generate addresses, and 2) I think that your proposition underestimates the difficulty of finding a collision immensely.  
> **username_33**: Regarding (2), will need to crunch some numbers on that, the variables are: the speed at which attacker(s) can create ECDSA public keys and check them against a list, the number of funded bitcoin addresses for which a key would be useful - certain parts of the equation are well known, for example we can assume reasonably that key distribution will be pretty even throughout the space (thus attacking only a portion of the space would be viable), and that there are roughly 2^96 private keys for each address.  
> **username_33**: Regarding (1), for any address which has spent an input and has remaining unspent inputs, the public ECDSA key is in the block chain, making checking much easier, for any address that has only received and not spent,t hen the ripemd-160 address in the blockchain which requires 2 extra steps of ripemd-160(sha256(ecdsa-public-key)) which makes it substantially more computationally expensive, much less so than computing a full address ala vanity address making.  
> **username_34**: Is there a pluggable crypto-technology built into the BitCoin architecture that can circumvent the inevitable?  
> **username_35**: Can you justify your calculations, please?  If RIPEMD-160 is secure, it should require roughly `2^80` keys to find a collision.  Generating a key takes much longer than an SHA-256 hash (and standard mining ASICs won't do it), so "THash" is not a useful measurement.  But even if you could do 1 tera-key per second, you have to do `2^40` keys to average one collision - that's about 34,000 years by my calculation - and even then, you'll probably just have found a collision with another key you generated, that doesn't actually contain anyone's coins.  
> **username_35**: And can you please explain  your remark about a 20 character match?   It sounds like you're claiming that the `2^256` possible private keys map to only `2^117` or so of the `2^160` possible addresses - that would seem to be a huge weakness in the hash algorithms used if true, and should be published in a leading crypto journal.  

---

### Answer by username_36 on 2017-08-16. Score: 0

I read on bitcoin.org that a private key $d\_A$ is any integer between $1$ and $n-1$. Also $n=FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE 0x00 = 18,446,744,073,709,551,615 0d00 $. Assuming 100M different addresses that is $5.42 e^{-12}$ probability of selecting a used address. If we have $x$ guesses, we need $x=$frac{1}{5.42e^{-12}}$ private keys to ensure finding one. That is $5.42 e^{12}$ address generation then for all 5.42 trillion randomly generated private keys generated, you would have to multiply $G$ by each private key $d\_n$ in the elliptical field to get the $Q\_n$ then search the bitcoin block chain for that $Q\_n$. After 5.42 trillion of them you would almost certainly find one and be able to steal its btc.

You could work out the computer science of this like how long to multiply $d\_n \times G$ and how long to search the block chain. Being as almost all wont be in it, it will be all worst case searches.

> **Comments:**
> **username_36**: I feel as if this is something that may happen occasionally however far to few to be considered a significant threat, at least for now as this problem won't scale like the block chain does. Also you can even average the amount of contained in a btc wallet, and work out the profitability, and I suspect it is low. Like you would go through all that just for the odds of stealing maybe 500 usd  

---

