# Is it possible to brute force bitcoin address creation in order to steal money?

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?

• 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. Aug 30 '11 at 21:42
• @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. Jun 18 '12 at 3:44
• @Pacerier Why would every user need 10k different addresses per day?
– Murch
Mar 28 '14 at 1:37
• @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?" Mar 29 '14 at 1:03
• @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?
– Murch
Mar 29 '14 at 19:32

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 hash of an ECDSA 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.

• The address spec is located at en.bitcoin.it/wiki/Protocol_specification#Addresses if anyone cares to double-check my edits :) Aug 30 '11 at 21:41
• Altered my opening sentence to indicate that "possible" is meant only in the strictest scientific sense of the word. Aug 30 '11 at 22:39
• @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. Feb 12 '12 at 16:13
• @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. Feb 12 '12 at 20:59
• @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. Jun 15 '12 at 18:15

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 and paste that private key into the 'wallet details' tab to get the corresponding Bitcoin address, then look it up on blockexplorer: $ 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 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.

• +1 for the interesting (though pratically useless) take, for the sausage, and for the cool closing sentence.
– o0'.
Mar 15 '12 at 10:34
• Really good explanation about "deterministic wallets". Thanks! Aug 6 '12 at 16:24
• 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? Jun 30 '13 at 15:30
• 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). Jun 30 '13 at 20:11
• 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: igor.host/index.php/goldendustproject, with pictures and all... Whew! can't explain it myself Jun 2 '18 at 16:50

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!

• 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)? May 12 '13 at 17:20
• 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 here. May 13 '13 at 10:13
• 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... Jan 4 '14 at 3:27
• @Peter you do have a point there.. Sep 7 '14 at 9:06
• @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. Mar 26 '15 at 19:01

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.

• It is possible, just highly unlikely and impractical. Aug 30 '11 at 23:41
• 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 ;) . Aug 31 '11 at 1:36
• 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... Aug 31 '11 at 14:33
• 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. Sep 1 '11 at 20:49
• @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." Sep 4 '11 at 18:26

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 has created coinkit, a python library for interacting with Bitcoin related stuff. In there, there is an example on how to use it 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.

• Can anyone explain why this answer is downvoted? I'd like to avoid mistakes in the future and I'm clueless. Oct 22 '15 at 14:58
• 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. Oct 22 '15 at 15:21
• 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! Oct 22 '15 at 16:50
• You did reference links not found elsewhere, and updated your answer with feedback. Thanks! Upvoted. Oct 22 '15 at 17:00

There is the LBC (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 of April 2017, LBC found over 30 Bitcoin private keys.

• 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. Nov 11 '17 at 21:30
• @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. Dec 29 '19 at 20:16
• @Michael It's literally in the LBC thread on Bitcointalk: bitcointalk.org/index.php?topic=1877935.msg18672178#msg18672178. Bounties were created solely for LBC. Dec 29 '19 at 22:04

If you prefer diagrams: http://i.imgur.com/ag3KQ0L.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) 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.

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.

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).

• -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. Oct 12 '11 at 1:58
• "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. Feb 6 '12 at 23:14

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.

• 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
Oct 24 '13 at 0:30
• 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. Oct 24 '13 at 12:33
• 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
Oct 24 '13 at 12:39
• 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. Oct 24 '13 at 14:22
• 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. Jan 27 '14 at 21:23

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.

• 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 Aug 16 '17 at 22:21