I don't think shor's algorithm helps because the address is a hash of the public key not the actual public key. Either Satoshi got reallly luck or he was some super genius who saw the threat of quantum computing. Since the public key is an unknown to the attacker they have no input for shor's algorithm.
Interesting! From what I've read, I think you're correct. Shor's algorithm is effective against asymmetric ciphers, not secure hash functions or symmetric ciphers (though Grover's algorithm promises somewhat improved performance in computing hashes and ciphers, but this isn't likely to result in any dramatic, overnight jumps in block computation). It would be a bit of an inconvenience though
you would always want to spend all bitcoins out of an address exactly once (because you do have to reveal the public key when you spend coins) and then never use that address again. After spending, since the public key has been revealed, any remaining coins at that address would be at risk (assuming a quantum computer could derive the private key in a timely fashion).
I'm guessing Satoshi was well aware of quantum based algorithms (Shor's has been known for a long time). Reading up on the application of these algorithms, it doesn't take much to realize that the strategic application of a secure hash function may be effective in mitigating the risk that quantum computing would pose. Using a hash of the public key has a practical benefit (shorter addresses), but I imagine Shor's was in the back of his mind as well.
It wouldn't be that much of a pain. Anytime you spend coins you spend all of them and by default the client uses a new address for change. So by default the "spending" address is empty after a spend. The only limitation would be the inability to re-use an address. Well more technically re-using an address would leave those funds potentially vulnerable (in a someday when quantum computers are powerful enough hypothetical way) to attack/seizure.
However if that risk evolved we likely would see evolution of the client software to mitigate it. For example say you have address 123 given to a mining pool and they periodically pay you. To avoid leaving funds at risk the client could mark that address as vulnerable and auto-sweep funds into a newly generated address thus the amount in the vulnerable address is always small and the the window of vulnerability is equally small.
Even more secure would be to pre-generate addresses and provide them to a periodic payer. For example you could generate 365 unique payment addresses and send them to your mining pool. Each day the mining pool uses the next one on the list.
Before anyone flips out I am not saying such protections are necessary but that the problems isn't "insolvable" even in a future when quantum cryptography is a threat to EC cryptogrpahy.
