It is currently understood that quantum computers could theoretically offer a quadratic speed-up in cracking hash function preimages using Grover's algorithm, and cubic speed-up in finding hash collisions using Brassard-Høyer-Tapp algorithm.
It is also understood that elliptic-curve cryptography would be the the first to go as it could be completely broken using Shor's algorithm.
We summarize this in the table below:
Primitive |
Conventional Computing Security Level |
Quantum Computing Security Level |
ECC-256 |
128 bits |
0 bits |
SHA-256 |
256 bits (preimage) / 128 bits (collision) |
128 bits (preimage) / 85 bits (collision) |
HASH-256 |
256 bits (preimage) / 128 bits (collision) |
128 bits (preimage) / 85 bits (collision) |
RIPEMD-160 |
160 bits (preimage) / 80 bits (collision) |
80 bits (preimage) / 53 bits (collision) |
HASH-160 |
160 bits (preimage) / 80 bits (collision) |
80 bits (preimage) / 53 bits (collision) |
From that we can say it is not so much about the algorithm - it is more about the hash function output size. Quantum computing doesn't break the algorithm but offers a speed-up for ANY algorithm, so all we'd need to do is pick one and increase the hash output size to 384 bits so we can maintain the 128 bits of security against collision attacks. BLAKE2 or SHA-3 would be good candidates. Even the SHA-2 familiy SHA-384 would be OK.
Actually implementing this in Bitcoin protocol would not be trivial, because a change of hash function would break a lot of software out there.