Can we please stop saying that it is improbable to generate an inuse key?

[HeliKopterBen]

If you actually do generate a duplicate key, I would be much more concerned about a flaw in the software used to generate the key.  Scrap that program and use a different method to generate keys.

[Ekaros]

If you actually do generate a duplicate key, I would be much more concerned about a flaw in the software used to generate the key.  Scrap that program and use a different method to generate keys.

How many of us have a way to generate secure(private) random data or even sufficiently random seeds... And I'm using random here for not pseudo-random that is seeded and then algorithmically generated...

[bountygiver]

If you did generated an in use wallet private key.
You just hit the world's lowest probability to win jackpot and you deserve to keep the money. :p
It's easier to get struck by lightning 10 days in a row than generating an in use wallet key.
http://what-if.xkcd.com/2/
Still easier than guessing all SAT questions right though.

[DeathAndTaxes]

How many of us have a way to generate secure(private) random data or even sufficiently random seeds... And I'm using random here for not pseudo-random that is seeded and then algorithmically generated...

Roll a bunch of dice?  Flip a bunch of coins?  It may not be particularly useful for random wallets where a new random private value is needed for each private key however it would be fairly easy to do for a deterministic wallet.

[freequant]

Because I'm sure we're all aware that due to the nature of random number generators, and implementations, the more widespread the adoption of Bitcoin, the more likely it is that we will see key collisions.

Are we even sure that ECDSA even has an unbiased distribution?

True, one should always speak in relative terms. You have as many chances of having a collision as you have chances of being killed by a 22-carat pure gold meteorite at the time you generate your key.

[Beliathon]

Because I'm sure we're all aware that due to the nature of random number generators, and implementations, the more widespread the adoption of Bitcoin, the more likely it is that we will see key collisions.

Are we even sure that ECDSA even has an unbiased distribution?

True, one should always speak in relative terms. You have as many chances of having a collision as you have chances of being killed by a 22-carat pure gold meteorite at the time you generate your key.

Or of being struck by lightning in the same spot 10,000 times in a row for seven weeks straight. And surviving to tell the tale.

[Lauda]

Or of being struck by lightning in the same spot 10,000 times in a row for seven weeks straight. And surviving to tell the tale.

Can we stop saying that it's improbable that this will happen?  

[lnternet]

It's 50:50. Either you generate an address that's already in use, or you don't.

[taturii]

To make myself clear I've done the calculation of the acumulative probability of a collision as the addresses are generated. This probability increases with the square of the number of generated addrsses. If we consider the most restrictive case: the 160 bit space of the public key hash, a 1% probabiliy of bitcoin addresses collision will be reached when 1.2x10^23 bitcoin addresses are generated. This means that a million machines generating 30 million addresses/second each would need a thousand years to reach a 1% probability of a single collision.

[DeathAndTaxes]

To make myself clear I've done the calculation of the acumulative probability of a collision as the addresses are generated. This probability increases with the square of the number of generated addrsses. If we consider the most restrictive case: the 160 bit space of the public key hash, a 1% probabiliy of bitcoin addresses collision will be reached when 1.2x10^23 bitcoin addresses are generated. This means that a million machines generating 30 million addresses/second each would need a thousand years to reach a 1% probability of a single collision.

Of course even that overstates the scenario in the OP which is a "inuse key".  Given the size of the key space in the highly improbable event of a collision it is very likely between two unfunded addresses created by the same mass creating entity.