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