Yes, the hash algorithm can be upgraded as computing power increases. This was foreseen and built into it from the beginning. The implementation is relatively flexible, and can be modified or upgraded in a number of ways without having to restart the blockchain.
Development of the technology is pretty active, you can observe what's being done on the development mailing list at Sourceforge:
That's just a random sample from Gavin, but if you're curious take 30m and read through to get a sense of what their issues and priorities are. The current issues list and recent change logs are also instructive;
> Yes, the hash algorithm can be upgraded as computing power increases. This was foreseen and built into it from the beginning.
It's not really "built-in".
Everybody would have to upgrade their bitcoin software, and then the new hashing algorithm would become active after a transitional period. The only thing in the bitcoin protocol which facilitates this is an alert system that can be used to broadcast warnings: https://en.bitcoin.it/wiki/Alerts
If a significant fraction of the bitcoin nodes is not upgraded, then the bitcoin network would be split in two.
This isn't true. There are several kinds of built in upgradeablility.
First, the relevant structures have version identifiers, so new clients could operate on a mixed network without problems (though with the new features disabled) and continue to parse old messages.
Secondly, all bitcoin transactions are governed by small programs written in the transactions (called scripts). Many of the scripting OP codes are 'reserved' and treated as NO-OP by the clients today. If a vulnerability was found in ECDSA and we needed to migrate off it fast— You could write transactions which require a (say) lamport signature PLUS an ECDSA signature.. and encode the lamport signature requirement in script as a NO-OP (e.g. one of the no-ops gets redefined a 'check lamport signature'). Old clients will ignore that requirement and consider the txn good if the ECC key was good, new clients will validate it. The network could run mixed for a long time, though transactions sent and received by old clients wouldn't enjoy the improved security.
The script mechanism doesn't let you upgrade everything, e.g. you can't change the hash used for the proof of work or merkle tree that way... but that aspect of the usage is the most robust against attack. E.g. Bitcoin would still be acceptably secure if MD5 were used in the POW as well studied functions tend to fail fairly slowly with attacks becoming more powerful gradually. For those things you're left with the alert... and even there the system can use indicators in coinbase to have mining nodes vote on when to activate the change.
Because no one mining would be left on the old network clients that didn't upgrade would just see transaction processing stop, not a significant split.
Development of the technology is pretty active, you can observe what's being done on the development mailing list at Sourceforge:
http://sourceforge.net/mailarchive/message.php?msg_id=284410...
That's just a random sample from Gavin, but if you're curious take 30m and read through to get a sense of what their issues and priorities are. The current issues list and recent change logs are also instructive;
https://github.com/bitcoin/bitcoin/issues
https://en.bitcoin.it/wiki/Changelog