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?


Posted 2011-08-30T21:26:59.183

Reputation: 11 179

one guy made a website,which generates random private keys. You must visit

– manan5439 – 2020-12-01T00:30:48.790

26To 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 – 2011-08-30T21:42:27.110

2@Pacerier Why would every user need 10k different addresses per day? – Murch – 2014-03-28T01:37:33.893

6@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 – 2014-03-29T01:03:53.837


@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 – 2014-03-29T19:32:56.900

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

– Murch – 2015-03-08T17:56:38.757

2@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 – 2012-06-18T03:44:14.470



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.

David Perry

Posted 2011-08-30T21:26:59.183

Reputation: 14 120


The address spec is located at if anyone cares to double-check my edits :)

– David Perry – 2011-08-30T21:41:24.907

@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 – 2011-11-04T16:23:26.027

@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 – 2011-11-04T16:36:08.633

@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 – 2011-11-04T16:48:33.063

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 – 2011-11-11T16:03:31.773

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 – 2011-08-30T21:51:17.760

16@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 – 2012-02-12T16:13:20.920

1@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 – 2012-02-12T20:59:20.327

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 – 2012-02-12T21:13:07.527

Downvoted because this use of "possible" is unlike that which any reader would suppose. – eMansipater – 2011-08-30T22:38:21.497

1Altered my opening sentence to indicate that "possible" is meant only in the strictest scientific sense of the word. – David Perry – 2011-08-30T22:39:42.303

@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 – 2012-06-15T17:41:11.207

@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 – 2012-06-15T17:50:55.620

@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 – 2012-06-15T18:04:18.800

1@Pacerier just FYI, the value of a day's efforts generating privkeys is nua 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 – 2012-06-15T18:14:20.053

2@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 – 2012-06-15T18:15:42.300


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; echo

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.

Chris Moore

Posted 2011-08-30T21:26:59.183

Reputation: 14 317

2what 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 – 2013-06-30T15:30:16.133

3That 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 – 2013-06-30T20:11:23.137

18+1 for the interesting (though pratically useless) take, for the sausage, and for the cool closing sentence. – o0'. – 2012-03-15T10:34:13.583

2Really good explanation about "deterministic wallets". Thanks! – Tomas – 2012-08-06T16:24:46.267


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:, with pictures and all... Whew! can't explain it myself

– Igor Soudakevitch – 2018-06-02T16:50:59.423


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!


Posted 2011-08-30T21:26:59.183

Reputation: 889

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 – 2013-05-12T17:20:12.803


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.

– Sjors Provoost – 2013-05-13T10:13:50.777

6Your 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 – 2014-01-04T03:27:47.297

@Peter you do have a point there.. – Mohd Abdul Mujib – 2014-09-07T09:06:52.573

4@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 – 2015-03-26T19:01:03.903


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.


Posted 2011-08-30T21:26:59.183

Reputation: 3 282

3Doing 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 – 2011-08-31T01:36:16.917

@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 – 2011-10-12T01:54:05.200

1@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 – 2011-10-12T14:09:04.413

1Or, 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 – 2011-10-12T14:18:09.867

@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 – 2011-10-12T15:05:27.767

1@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 – 2011-08-31T13:45:49.057

14If 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 – 2011-08-31T14:33:44.050

I was just wondering how you know the age of the universe? – shoeless joe – 2011-11-15T06:44:10.643

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 – 2011-11-17T23:52:10.587

1And yes, Gavin, it is possible for my body to suddenly explode, especially on New Years Eve... dude, that was quite a party....:-) – shoeless joe – 2012-01-03T21:22:47.780

1Yes, 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 – 2011-09-01T20:42:49.413

2Oh 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 – 2011-09-01T20:49:41.090

6@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 – 2011-09-04T18:26:22.817

@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 – 2011-09-04T18:29:08.790

11It is possible, just highly unlikely and impractical. – Simon Trigona – 2011-08-30T23:41:17.107


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

Dennis Decoene

Posted 2011-08-30T21:26:59.183

Reputation: 289

Can anyone explain why this answer is downvoted? I'd like to avoid mistakes in the future and I'm clueless. – Dennis Decoene – 2015-10-22T14:58:45.157

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 – 2015-10-22T15:21:23.993

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! – Dennis Decoene – 2015-10-22T16:50:52.887

1You did reference links not found elsewhere, and updated your answer with feedback. Thanks! Upvoted. – morsecoder – 2015-10-22T17:00:31.930


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.


Posted 2011-08-30T21:26:59.183

Reputation: 41

@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 – 2019-12-29T20:16:25.940

@Michael It's literally in the LBC thread on Bitcointalk: Bounties were created solely for LBC.

– Andrew Chow – 2019-12-29T22:04:47.737

5Those 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. – Andrew Chow – 2017-11-11T21:30:15.170


If you prefer diagrams: (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: (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.


Posted 2011-08-30T21:26:59.183

Reputation: 141


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.


Posted 2011-08-30T21:26:59.183

Reputation: 1 421


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


Posted 2011-08-30T21:26:59.183

Reputation: 75

-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 – 2011-10-12T01:58:11.330

2"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 – 2012-02-06T23:14:55.463


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.


Posted 2011-08-30T21:26:59.183

Reputation: 219

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 – 2013-10-24T00:30:31.750

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 – 2013-10-24T12:33:33.113

1That 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 – 2013-10-24T12:39:28.370

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 – 2013-10-24T14:22:54.673

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 – 2013-10-24T14:25:09.100

Is there a pluggable crypto-technology built into the BitCoin architecture that can circumvent the inevitable? – Robert Christian – 2013-12-23T05:59:22.703

1Can 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 – 2014-01-27T21:23:43.863

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 – 2014-01-27T21:27:22.080


I read on 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.

marshal craft

Posted 2011-08-30T21:26:59.183

Reputation: 189

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 – 2017-08-16T22:21:36.520