Bitcoin Core estudia cambiar su criptografía para protegerse de la computación cuántica

Desarrolladores de renombre de Bitcoin analizan alternativas poscuánticas, discuten limitaciones técnicas y buscan soluciones seguras antes de la llegada de computadoras cuánticas avanzadas.

Aunque defensores de la criptografía de Bitcoin como Adam Back y Jimmy Song defienden que la computación cuántica no representa ningún riesgo para la seguridad de BTC, desarrolladores de Bitcoin Core reconocen que, aunque la amenaza aún parezca distante, la necesidad de protección debe tratarse con antelación.

La discusión cobró fuerza recientemente en el grupo de debates de Bitcoin Core, tras una serie de análisis públicos realizados por desarrolladores respetados en el área de criptografía, como Mikhail Kudinov, Jonas Nick, Greg Maxwell, Conduition, Boris Nagaev y Olaoluwa Osuntokun.

El tema es delicado porque cualquier cambio como este en la base del código de Bitcoin exige un hard fork, que depende del consenso entre todos los participantes, incluyendo desarrolladores, operadores de nodos, los exchanges de criptomonedas, comunidades, empresas y, principalmente, mineros, que serían los más afectados en el caso, ya que las ASICs actuales perderían sus funciones; es decir, todos los mineros tendrían que cambiar sus máquinas.

Entre los participantes de las discusiones, hay consenso de que el trabajo debe comenzar ahora, incluso si la ejecución se produce a lo largo de varios años. La meta es impedir que futuras computadoras cuánticas avancen sobre los mecanismos actuales de firma basados en curvas elípticas.
Opciones poscuánticas para Bitcoin

Las conversaciones cobraron impulso después de que Mikhail Kudinov y Jonas Nick, investigadores de Blockstream, publicaran un análisis detallado sobre esquemas de firmas resistentes a la computación cuántica. Ellos defienden que las soluciones hash-based, como SPHINCS+ y SLH-DSA, ofrecen seguridad al depender únicamente de la fuerza de las funciones hash, algo ya fundamental en Bitcoin.

En el documento y en los mensajes enviados al grupo de desarrolladores, Kudinov y Jonas Nick mostraron cómo los ajustes en los parámetros pueden reducir significativamente el tamaño de las firmas. En escenarios controlados, sería posible reducir las firmas de casi 8 KB a aproximadamente 4 KB. Además, reforzaron que las claves públicas de estos esquemas son extremadamente pequeñas, lo que representa un punto positivo para las carteras y dispositivos de bajo consumo.

Greg Maxwell, uno de los desarrolladores más respetados del ecosistema, añadió una crítica importante. Destacó que cualquier aumento en el tamaño de las firmas debe evaluarse considerando el impacto en la verificación de bloques completos. Como señaló Maxwell, los bloques llenos de firmas grandes pueden elevar el costo de validación a niveles preocupantes.

La visión de Maxwell influyó directamente en el rumbo de la conversación, recordando que la seguridad de Bitcoin depende de la capacidad de cualquier persona de verificar bloques con hardware simple. Así, la eficiencia no puede sacrificarse.
Debates sobre derivación de claves con SLH-DSA y ML-DSA

En este punto, Conduition presentó uno de los análisis más técnicos. Discutió el desafío de usar firmas hash-based en carteras determinísticas compatibles con el estándar BIP32. Según él, SLH-DSA no posee una estructura matemática que permita derivar claves públicas de la misma forma que ocurre hoy con las carteras HD.

Conduition sugirió investigaciones sobre alternativas como ML-DSA y SQIsign, que podrían ofrecer medios de derivación más flexibles, aunque todavía sin propuestas concretas. También explicó que una posible solución sería construir árboles Taproot conteniendo:

• una clave SLH-DSA estática;
• claves derivadas de esquemas estructurados como ML-DSA;
• y una clave Schnorr derivada por el BIP32 tradicional.

Esta propuesta llamó la atención por su creatividad, pero generó preocupaciones. Conduition señaló que, al usar SLH-DSA de forma repetida, un usuario podría exponer conexiones entre direcciones, perjudicando la privacidad. La solución sugerida implica el uso de nonces aleatorios para evitar la repetición de hashes en tap trees.

Desafíos prácticos en dispositivos reales

Olaoluwa Osuntokun, conocido por su trabajo en la Lightning Network, profundizó el debate al presentar estudios sobre el rendimiento de firmas poscuánticas en hardware real. Citó benchmarks de Trezor que muestran que una única firma SLH-DSA puede tardar hasta 75 segundos en dispositivos compactos.

Osuntokun también mencionó investigaciones que exploran la derivación jerárquica en esquemas poscuánticos. Entre ellas se encuentra el estudio sobre DilithiumRK, una modificación de ML-DSA que posibilita una derivación similar a BIP32, pero con elevados costos de rendimiento.

Su intervención dejó claro que el futuro de las carteras dependerá de nuevos chips, aceleradores de hash o pequeños FPGAs. Sin ello, las firmas poscuánticas pueden volverse imprácticas para usuarios comunes.

Otro punto recurrente en las discusiones fue la necesidad de alineación con los estándares definidos por el NIST, el organismo responsable de la estandarización de la criptografía poscuántica. Algunos desarrolladores defienden el uso de las versiones oficiales de los algoritmos. Otros, como Conduition, creen que Bitcoin puede adoptar parámetros personalizados, manteniendo la compatibilidad con el algoritmo base, pero creando beneficios prácticos.

Boris Nagaev también contribuyó con análisis profundos sobre multisig y computación multipartita (MPC). Evaluó la posibilidad de producir firmas hash-based usando MPC para transformar un multisig tradicional en una firma única. Sin embargo, después de los cálculos, percibió que este proceso sería demasiado lento y pesado, lo que hace que la idea sea impracticable a corto plazo.

Kudinov complementó que, según estudios citados por él, generar una única firma SPHINCS+ vía MPC podría llevar más de 85 minutos, lo que saca la solución del campo operacional.

Fuente: CoinTelegraph

Suscríbete a nuestro Boletín