It would happen in feature.

There have been uncertainties concerning the security of ECDSA.
We still don't know how they chose the curve params and it doesn't seem that they are going to tell us.

It would be useful to at least add support for RSA/DSA signed transaction, in parallel to the ECDSA.
Then people could at least diversify their savings - e.g. split it 50:50 between ECDSA and RSA protected addresses.

This kind of change needs a hard fork and so the sooner you put it in, the better.

We are not talking about bruteforcing, per se.

The whole security of ECDSA is based on the assumption that the sign function (which takes the hash, random R and private key D, calculating S that corresponds to the public key) cannot be reversed with far fewer resources, using some not yet publicly known algorithm.

The math behind it is quite complex and the mathematicians are not entirely certain whether it is in fact impossible to reverse the function.
In other words: it has not been mathematically proven that it is impossible to calculate D, having the public key, the hash, R and S.

Moreover: we know for sure that if you reuse the same R with a different hash, the way to calc D is pretty straight forward.
Now, using a different R the only thing that makes calculating D not straight forward is a magic behind a shape of the curve...
And the curve has been shaped by people who don't tell us how they did it

Use a new address for every transaction (as suggested in the white paper).

Problem solved.

Now, the only way to steal coins is to reverse the RIPEMD-160 hash function to find a valid SHA-256 hash
AND
then reverse the SHA-256 hash function to find a valid public key
AND
then reverse the public key generation to find a valid private key

All without having a signature to work from.

If any one or two of these functions become weak due to some newly discovered exploit, the bitcoins will continue to be protected by the remaining functions, allowing time for the bitcoin community to replace the weakened cryptographic functions.

To put this into perspective, if we cloned the fastest supercomputer in the world right now and made one for every atom in not one, but 100,000 people, we would have the capability to crack Bitcoin addresses through brute force.

Math: (speed of current top super in flops, times amount of atoms in a human times 100,000, this gives 1 order of magnitude larger than needed to assume 10 flop operation equilviant is required for creating a Bitcoin addresses and testing balance)
http://www.wolframalpha.com/input/?i=38+x+10%5E15+x+7+x+10%5E27+x+10%5E5

Top super: http://en.wikipedia.org/wiki/Tianhe-2

Anything is possible, I remember people saying Litecoin is anti FPGA..

Poor choice of words on my part.

When I said "reverse the . . . hash function", I meant to do the opposite of what the hash function is intended to do, regardless of the method chosen.

In other words, a hash function is designed to provide a digest when given a message.

When I say "reverse the . . . hash function", I mean to provide a message when given its digest. The conditions on the message being that it is exactly 256 bits long and has the given digest as the result of performing the intended hash on it.

If one day something about Bitcoin is cracked, it will be fixed, bogus transactions reverted by miners, some people will lose some money and then life will go on. Abandoning Bitcoin is equivalent to everyone losing all their wealth. That's not going to happen without a fight.

i think litecoin must be future