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

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.