Y aunque sea algo inevitable, aveces siento algo de frustración por la aparente inacción que puede mostrar el equipo de desarrolladores.
Sobre esto hubo muchas discusiones "en el norte". Sin embargo, ahí estoy de acuerdo con los desarrolladores. El tema no es tan urgente como algunas empresas vinculadas a Google, IBM etc. lo quieren presentar, por lo cual queda tiempo para elegir un algoritmo "post-cuántico", y sobre todo: que los expertos investiguen aún mejor el tema. Acá en el foro particularmente hay unos fans muy molestos de una altcoin que ya se presenta como "segura contra ataques cuánticos" y la promocionan en el foro con hilos y posts para generar miedo.
Siempre hay que recordar: probablemente antes del Bitcoin estará en peligro tu cuenta en el banco. ¿O alguien conoce un banco que ahora asegura su homebanking con criptografía post-cuántica?
En BTC el "panorama" se presenta aproximadamente así: Hay tres posibles amenazas, cada una más difícil que la anterior.
1. Es posible que en 5, 10 o 15 años alguien logre robar coins de claves P2PK (coins de satoshi etc.), "minando" durante años con una computadora cuántica de un par de miles de cúbits. Esto sería el primer blanco, ya que los "ladrones cuánticos" tendrán mucho tiempo.
2. El próximo paso pueden ser las claves/direcciones re-utilizadas, comenzando por las que parecen no moverse mucho. Aquí ya estaríamos hablando de ya probablemente decenas o centenares de cúbits, ya que hay que apurarse por si el dueño de la cartera decide gastar los BTC.
3. El tercer paso, y ahi ya hablamos de un futuro muy lejano (décadas en adelante), sería un ataque a transacciones en la mempool, es decir a claves públicas publicadas en el momento de enviarse BTC, que todavía no se han confirmado. El desafío no es menor: Hay que hackear la clave en menos de 10 minutos, para crear una transacción con más fees hacia una cartera propia, y luego encima si hay varios ladrones cuánticos dando vuelta, es posible que se hackeen las claves entre si, o sea se exponen también a un riesgo.
Recién para el paso 3 sería urgente un cambio de algoritmo. En cambio para las primeras dos amenazas, basta con no reutilizar los coins nunca.
Cuando el primer blanco (un coin "perdido" de un minero de 2009/10) haya sido atacado, con o sin éxito, creo que ya mucha gente "despertará" y moverá los coins a direcciones no utilizadas previamente. Y recién en este momento, probablemente décadas antes de que un ataque del tipo 3 sea posible, los desarrolladores deberían implementar el algoritmo que más seguro sea. Antes no.
Pequeño comentario:
sustituir el sha256.
Como Shawshank ya escribió correctamente no se trata del algoritmo para hashes (SHA256) lo que estaría en peligro, sino ECDSA. ECDSA es el sistema de clave pública/privada, mientras que SHA256 es el sistema para generar los hashes de los bloques y las direcciones. Para amenazar a los hashes SHA256 aparentemente el algoritmo de Shor no sirve.