Topic: Is it possible to generate the same adress twice? - page 2. (Read 5726 times)

"quantum physics" doesn't work that way. What you're probably talking about is quantum computers, which can solve certain problems faster than a traditional computer.

^^
....and comprehension finally dawns.


HOLY SMOKE !    

Well significantly longer.

A perfect computer, that is one that operates at the thermodynamic limit in absolute zero, using all the available energy of our sun can't count to 2^256 in the next 4 billion years before our sun burns out.  Yes we are talking far future science fiction, like using all the matter in our solar system to construct a star system sized super computer and the dyson sphere around the sun to power it.

This is just counting 0, 1, 2, 3, .... 2^256.  It isn't based on any current or future (Moore's law) computing power but the thermodynamic limit which is the efficiency limit of any cryptographic system.  Per linked article below you would need to capture the entire output of a supernova to has sufficient energy to count to 2^216 so given a sufficient number of perfect computers and the ability to capture without any loss the energy output of a super nova if you found and used roughly 1 trillion super novas one could count through all possible values o to 2^256.

I think Bruce Schneier says it best


http://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html

DISCLAIMER (as people have taken this out of context before):
ECDSA like all public key cryptographic systems rely on certain mathematical properties to remain secure.  ECDSA relies on the fact that finding a discrete logarithm of an elliptic curve element with respect to a publicly known base point is computationally infeasible.  This is known as the discrete logarithm problem.   A common misnomer is that ECDSA relies on factoring large numbers but that applies to other systems like RSA which are not used in Bitcoin.  This principal has so far remained true and as such no faster than brute force attack exists at the current time.  Likewise a brute force attack while possible is infeasible due to the energy requirements of a 256 bit keyspace.  However like all public key cryptography, it is possible that ECDSA will eventually be compromised due to a flaw in its design or underlying principal allowing faster than brute force attacks.  Depending on the severity of the compromise it *may* be possible in the future to find a private key from a public key in a reasonable amount of time/energy.    The above cite is only based on brute force attack against a 256 bit private key like what would occur by computers randomly generating keys that happen to be one which is already in use.  Of course if ECDSA becomes degraded the Bitcoin protocol could be extended to use new more secure address types and smart users would migrate their funds to more secure addresses.  In the event of such a compromise (or quantum computing attack) Bitcoin provides a secondary layer of security by making the address a hash of the public key.  The public key is not known until funds are spent.  If one does not reuse addresses there is no known public key to attack against.

Just to give all a complete understanding on the scale of probability.

Can anyone give an estimate as to how long it would take the ENTIRE network hashing simultaneously to crack one address with a big balance ?   

In case one does, it's finders keepers so.

Personally I am importing the blockchain into a MySQL database and will be creating a list of bitcoin addresses with a balance of X coins that have not been touched in a long time, compile that list into a single file and run my CPU Address bruteforcer on it.

With my 30k list of addresses, I am generating about 800k addresses per second(even when comparing each and everyone of these 800k to the list)(on a single core). I am not even using any binary search trees.

If I were to port this code to a GPU, it would be orders of magnitudes faster. Hey, it may take a billion years to get a single address, but I am doing for the fun.

Clients don't know if an address already exists only if it has already been used.  Also coding that would be like coding your website to display .... "sorry we are offline because our lead developer was just hit by 12 metorites while being eaten by a shark" just in case that happens.

Everyone it seems in agreement. Yes its possible but no, it's so unlikely there is no need to worry about it.

OK but wouldn't it be fairly simple to have an automatic check within all the clients and a simple prompt ..
 'this key pair already exits please try again'

Getting Deja-vu on this topic but its nice to rehash once in a while. 

short answer yes, long answer no

~~~then the weakest computer forces the trade sweet~! ?lol

Changing the  user data into a private key with sha256 can be done very quickly, however obtaining the public key from this private key requires ellipitical key multiplications.
This takes significantly longer. From my test using OpenSSL on a single cpu core on a reasonably fast machine, it can manage 1000 per second. So a 3 word pass phrase from a set of 10000 words will take 15 years on average to brute form.

The comparison I heard before was the chance of getting duplicate private keys by chance, is the same as getting struck by lightning every minute for the next 60 years.

Christ. That's a nice deterrent.

'Execution time 1.0590908527374 seconds'

I made a quick calculator here; http://rackverse.com/pbkdf2/index.php ; (don't use your real passwords etc)

I completely agree, but (referring specifically to the italicized portion), I'd question whether saying it so narrowly might reinforce some layperson's misperception that, at the end of the day, there's something just a little bit (even if almost-infinitessimally) less "secure," "certain," or "real" about public key cryptography and the infrastructure built upon it, when compared to analogs in the everyday physical "real world".  But really, you reach a point where the odds of a thing happening become so vanishingly small that it is useful to compare it with the odds of similarly ultra-extremely-remote things happening (like the comments others have made about getting hit by lightning 10 times in a minute, or winning the lottery 3 times in a row).

(E.g., imagine a mathematically-skeptical goldbug who says "well, you can't tell me with *absolute 100% certainty* that there won't be a colision allowing someone else to spend my BTCs? Forget that, I'm sticking with my gold bullion bars!"  Even setting aside the issues of assaying your gold to make sure it's real, and securing it and guarding it to protect it from being stolen by thieves or washed away in a tsunami or vaporized in a bomb blast, I could respond, "you can't be *absolutely 100% certain* that all of the atoms of gold in those bars won't spontaneously decay into lighter elements and alpha, beta and gamma rays" -- and for a sufficiently high level of computational complexity, the odds of those things may be roughly equal.)

No real deep point here, other than -- as seems to have a habit of happening in the Bitcoin world -- when you start to focus on what seems weird or troubling or risky or disconcerting, tahat can have a way of revealing how there's a lot that's equally weird or troubling or risky or disconcertaing about things existing world that you've alwways just taken for granted, in ways that you'd never really thought about ("oh, you mean it's turtles all the way down...?")...

Technically, yes. Like winning powerball three times consecutively is possible.
 
 

They would have the same private key, yes.


Most do not.


Addresses are only recognized after they have received a transaction. I can have five million addresses in my wallet. Only if someone sends bitcoins to them does the blockchain have a record of their existence.




There doesn't need to be one. The chances of an address collision are so low that it will likely never happen in a 1,000 human lifetimes.



Yes



The blockchain is agnostic to the private keys behind an address. One can even send bitcoins to an address without a known private key effectively destroying the coins until quantum computers can find the private key again.

The situation you described would result in two parties having access to the funds.


I hoped this helped.

What timeframe are we talking about here for the generation of a key with your example?

I wouldn't say "most".  Almost all private keys (addresses are never random) created randomly with the small minority being brainwallets.  People using brainwallets should understand the security implications and should always add salt to their passphrase.  Remember salt is merely to add entropy it doesn't need to be a secret.  You can email the salt to yourself (and others) in plaintext.   The point of the salt is to prevent an attacker for just doing an attack against all possible keys using a dictionary.  If an attacker learns your salt then he can employ a dictionary or brute force attack against your private key however at that point you are no weaker than if you used no salt.

SHA256 is also a horribly "fast" algorithm.  This is bad in key derivitive functions.  One should consider using a function like PBKDF2 or bcrypt to generate the private key.  These functions use thousands of iterations and thus the time to attempt one key is greatly increased.

Had the person who was brute forced done this:

privatekey = PBKDF2("password",8347389412748942,83473) where the first value is the passphrase, the second is the salt, and the third is the number of rounds it is unlikely he would have lost funds. Neither the number of rounds or salt is a secret.  It should be stored in multiple locations to ensure it isn't lot.

1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T is the address for 'correct horse battery staple', and I'm sure there's more than owner for that private key 

Best answer so far. 

I had the same question once.

The possibility is so low , practically zero , that makes collision the absolute last thing you should
worry about in this world.

Possible but improbable.  That can be kind of disconcerting to people but understand this same "issue" existing in all public key cryptography.  For example I could just happen to create a private key that would allow me to impersonate your bank's SSL cert.  I could just happen to create a PGP private key which unlocks someone else encrypted messages.

It is possible but so improbable as to be considered essentially zero.