Timeline for Is it possible to brute force bitcoin address creation in order to steal money?
Current License: CC BY-SA 3.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 1, 2023 at 20:21 | comment | added | user4276 | You state "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.". With miner hashing so much higher than it was in 2011, is it still true today? Would it really be massively more profitable to mine than to try to find addresses (collisions?) that already have a balance and steal them? | |
| Jun 15, 2012 at 18:15 | comment | added | David Perry | @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, 2012 at 18:14 | comment | added | David Perry | @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. | |
| Jun 15, 2012 at 18:04 | comment | added | Pacerier | @DavidPerry Ic. But quantum computing won't stay stuck in the lab isn't it? Computers weren't stuck in labs for too long. | |
| Jun 15, 2012 at 17:50 | comment | added | David Perry | @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. | |
| Jun 15, 2012 at 17:41 | comment | added | Pacerier | @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? | |
| Feb 12, 2012 at 21:19 | history | edited | David Perry | CC BY-SA 3.0 |
added 570 characters in body
|
| Feb 12, 2012 at 21:13 | comment | added | David Perry | 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. | |
| Feb 12, 2012 at 20:59 | comment | added | Chris Moore | @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, 2012 at 16:13 | comment | added | Chris Moore | @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. | |
| Nov 11, 2011 at 16:03 | comment | added | David Perry | 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. | |
| Nov 4, 2011 at 16:48 | comment | added | DeathAndTaxes | @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? | |
| Nov 4, 2011 at 16:36 | comment | added | David Perry | @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. | |
| Nov 4, 2011 at 16:23 | comment | added | DeathAndTaxes | @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. | |
| Sep 1, 2011 at 12:36 | vote | accept | nmat | ||
| Aug 31, 2011 at 14:47 | history | edited | eMansipater | CC BY-SA 3.0 |
fixed "possible" wording
|
| Aug 30, 2011 at 22:55 | review | Suggested edits | |||
| Aug 31, 2011 at 0:24 | |||||
| Aug 30, 2011 at 22:39 | comment | added | David Perry | Altered my opening sentence to indicate that "possible" is meant only in the strictest scientific sense of the word. | |
| Aug 30, 2011 at 22:39 | history | edited | David Perry | CC BY-SA 3.0 |
added 65 characters in body
|
| Aug 30, 2011 at 22:38 | comment | added | eMansipater | Downvoted because this use of "possible" is unlike that which any reader would suppose. | |
| Aug 30, 2011 at 21:51 | comment | added | Buckhead_Comp_Ser_Co | Double check and repost what you find, this site is better then the wiki, lets put the information here instead of there. | |
| Aug 30, 2011 at 21:41 | comment | added | David Perry | The address spec is located at en.bitcoin.it/wiki/Protocol_specification#Addresses if anyone cares to double-check my edits :) | |
| Aug 30, 2011 at 21:40 | history | edited | David Perry | CC BY-SA 3.0 |
added 284 characters in body
|
| Aug 30, 2011 at 21:32 | history | answered | David Perry | CC BY-SA 3.0 |