Bitcoin no es invulnerable a la computación cuántica. Es solo que todavía no importa.

Y mientras la comunidad discute cuántos bytes caben en un OP_RETURN, el reloj ya corre.

La narrativa más repetida en los círculos de Bitcoin cuando sale el tema cuántico es alguna variante de: “los expertos dicen que faltan décadas” o “hay problemas más urgentes”. Ambas afirmaciones son técnicamente defensibles. Ambas son también una forma cómoda de no hacer nada.

La verdad incómoda es esta: Bitcoin tiene hoy una resistencia post-cuántica accidental, parcial y que se erosiona con cada bloque que se mina. No es una propiedad diseñada. Es una consecuencia de cómo funciona el protocolo que, con el tiempo y sin intervención, desaparecerá.

Entender por qué requiere separar tres capas que la comunidad suele mezclar: la criptografía de curva elíptica que protege las firmas, el hashing que protege las direcciones, y la exposición real de las claves públicas en la cadena. Ahí está todo el argumento.

Por qué Bitcoin resiste hoy, pero no por diseño

Bitcoin usa dos primitivas criptográficas que tienen perfiles de vulnerabilidad cuántica radicalmente distintos: las firmas digitales basadas en criptografía de curva elíptica (ECDSA sobre secp256k1), y las funciones de hash (SHA-256 y RIPEMD-160) que protegen las direcciones.

Las firmas digitales se basan en ECDSA sobre la curva secp256k1. El algoritmo de Shor puede romper la criptografía de curva elíptica en tiempo polinomial con un computador cuántico suficientemente grande y con corrección de errores. Esto no es especulación; es matemática establecida desde 1994. Una vez que exista un computador cuántico con ~3.000 qubits lógicos estables (la estimación más citada en la literatura reciente es entre 2.000 y 4.000 qubits lógicos para ECDSA-256), cualquier clave pública expuesta puede tener su clave privada derivada.

Las direcciones, en cambio, son hashes. Una dirección Bitcoin típica (P2PKH, P2SH, Bech32) es el resultado de aplicar SHA-256 y RIPEMD-160 sobre la clave pública. El algoritmo de Grover puede acelerar la búsqueda en funciones hash de forma cuadrática, lo que reduce efectivamente la seguridad de SHA-256 de 256 bits a 128 bits equivalentes clásicos. Eso sigue siendo computacionalmente irrelevante para cualquier atacante en el horizonte visible. Grover no rompe SHA-256; lo debilita a algo que sigue siendo perfectamente seguro.

La defensa real de Bitcoin hoy es esta: mientras la clave pública no esté expuesta, no hay nada que Shor pueda atacar. Y en el modelo UTXO de Bitcoin, la clave pública solo se revela en el momento de gastar. Antes de eso, lo que la red conoce es el hash de la clave pública. Un atacante cuántico que no puede ver la clave pública no puede usar Shor para derivar la clave privada.

Esto es resistencia cuántica real, pero es condicional y depende completamente del comportamiento del usuario y de la arquitectura de las direcciones.

Dónde se rompe esa defensa

Existen tres vectores de exposición que hacen que la resistencia actual sea frágil en la práctica.

El primero es la reutilización de direcciones. Cada vez que se gasta desde una dirección, la clave pública queda expuesta en la firma de la transacción. Si alguien vuelve a recibir fondos en esa misma dirección, esos fondos están protegidos únicamente por ECDSA, con clave pública ya conocida por toda la red. Cualquier computador cuántico suficientemente capaz podría derivar la clave privada y robar esos fondos. La reutilización de direcciones es un problema conocido, ampliamente denunciado, y ampliamente practicado. Exchanges centralizados, wallets mal diseñadas, y usuarios que copian y pegan “su dirección de Bitcoin” como si fuera un IBAN o un CBU siguen generando este problema a escala.

El segundo es el período de confirmación. Cuando una transacción es emitida a la red pero aún no está confirmada, la clave pública está expuesta y la transacción puede ser reemplazada (si RBF está habilitado) o hay una ventana temporal donde un adversario cuántico lo suficientemente rápido podría firmar una transacción competidora con la clave privada derivada. Este ataque requiere que la derivación cuántica sea más rápida que el tiempo de confirmación, lo que hoy no es el caso, pero establece un umbral concreto de urgencia: cuando un computador cuántico pueda hacer esto en minutos, el protocolo tiene un problema inmediato sin necesidad de reutilización de direcciones.

El tercero es el volumen de Bitcoin en direcciones P2PK legadas. Las primeras transacciones de Bitcoin, incluyendo los bloques minados por Satoshi, usaban Pay-to-Public-Key en lugar de Pay-to-Public-Key-Hash. En P2PK la clave pública está directamente en el script de bloqueo. No hay hash que oculte nada. Se estima que alrededor de 1,7 millones de BTC siguen en outputs P2PK, con clave pública completamente expuesta. Entre ellos, casi con certeza, los bitcoins de Satoshi. Son fondos que no se han movido desde los primeros años y que un computador cuántico maduro podría drenar sin depender de ningún fallo de comportamiento del usuario.

El horizonte real: ni mañana ni nunca

El argumento de “faltan décadas” merece ser desmenuzado porque es frecuentemente impreciso.

Lo que los investigadores dicen con más rigor es que los computadores cuánticos actuales con corrección de errores práctica no existen todavía. Los dispositivos de IBM, Google, y otros miden qubits físicos, no lógicos. La corrección de errores cuánticos requiere miles de qubits físicos por cada qubit lógico útil. El gap entre lo que existe hoy y lo que se necesita para atacar ECDSA-256 es genuinamente grande.

Pero “grande” no es lo mismo que “manejable con tranquilidad”. Bitcoin funciona con un horizonte de seguridad que debe medirse en décadas, no en años. Una transición criptográfica a nivel de protocolo, con el nivel de consenso distribuido que Bitcoin requiere, tarda años. NIST completó su proceso de estandarización post-cuántica en 2024, después de ocho años de trabajo. Implementar cualquier esquema análogo en Bitcoin implica propuestas BIP, debate, implementación en los clientes, activación por soft fork o hard fork, y adopción gradual. Si ese proceso empieza cuando el riesgo ya es inminente, llega tarde.

El argumento correcto no es “tenemos décadas”. El argumento correcto es “el tiempo que tenemos es suficiente solo si empezamos a usarlo ahora”.

Qué habría que reforzar y cómo

La comunidad técnica ya tiene claridad sobre las direcciones de trabajo. El problema no es falta de conocimiento; es falta de prioridad.

Firmas post-cuánticas en el protocolo. NIST estandarizó en 2024 ML-DSA (antes conocido como CRYSTALS-Dilithium) como el esquema de firma digital post-cuántico primario. También SLH-DSA (SPHINCS+) como alternativa basada en hashes. Ambos son candidatos para reemplazar ECDSA en Bitcoin. El problema es que las firmas Dilithium tienen entre 2.400 y 4.900 bytes según el nivel de seguridad, comparado con los ~72 bytes de una firma ECDSA. Eso es un aumento de tamaño de 30 a 70 veces. En términos de capacidad de bloque, representaría una reducción brutal del throughput a menos que se adopten compromisos adicionales.

Hay investigación activa en esquemas más compactos. FALCON (también estandarizado por NIST como FN-DSA) produce firmas de ~690 bytes, más manejables, aunque con complejidad de implementación significativa por su aritmética de retículos sobre polinomios gaussianos. El trabajo de diseño del esquema óptimo para Bitcoin, balanceando tamaño, seguridad y verificación eficiente, es no trivial y no ha recibido la atención que merece dentro de los canales de desarrollo del protocolo.

Migración de UTXOs vulnerables. El problema de los 1,7 millones de BTC en P2PK es especialmente delicado porque algunos de esos fondos son probablemente de personas que perdieron acceso a sus wallets, y otros son casi certeza del propio Satoshi. Cualquier propuesta que permita confiscar o quemar esos fondos enfrenta objeciones filosóficas profundas sobre la inmutabilidad del ledger. Sin embargo, la alternativa de no hacer nada y dejar esos BTC como botín para el primer actor cuántico suficientemente capaz tampoco es una posición neutral: tiene consecuencias sobre el precio, sobre la narrativa de seguridad, y sobre la legitimidad del sistema.

Una propuesta intermedia que ha circulado es establecer una fecha de migración forzosa, a muchos años de distancia, con advertencia extensa, después de la cual los outputs P2PK se consideren no gastables. Es polémico. Pero la conversación tiene que ocurrir.

Direcciones basadas en hashes resistentes. Taproot (P2TR) usa Schnorr sobre secp256k1, no ECDSA. Eso no lo hace post-cuántico; sigue siendo vulnerable a Shor. Pero la arquitectura de Taproot, con su árbol de scripts y la separación entre clave interna y clave de tweaked, es más fácil de extender hacia esquemas híbridos. Hay propuestas académicas de esquemas híbridos ECDSA+Dilithium donde ambas firmas deben ser válidas, lo que hace que un atacante necesite romper simultáneamente un algoritmo clásico y uno post-cuántico. Esa transición incremental, que no requiere abandonar la seguridad clásica mientras se agrega la post-cuántica, es probablemente el camino más pragmático para Bitcoin.

Lo que la comunidad debería dejar de hacer

En el momento en que escribo esto, una fracción desproporcionada de la energía técnica y política de la comunidad Bitcoin está consumida por el debate sobre el límite del campo OP_RETURN.

Para quienes no estén en el detalle: OP_RETURN es un opcode que permite almacenar datos arbitrarios en transacciones Bitcoin marcándolos explícitamente como no gastables. El debate actual gira en torno a si Bitcoin Core debería aumentar o eliminar el límite predeterminado de 83 bytes de datos en estos outputs, versus si hacerlo abre la puerta a uso no-financiero de la blockchain que algunos consideran spam y otros consideran legítimo.

Es un debate real. No es un debate trivial. Tiene implicaciones sobre la política de mempool, sobre la naturaleza del protocolo, y sobre qué se considera uso válido de Bitcoin.

Pero es también un debate sobre bytes de metadatos en un campo de datos arbitrarios, mientras la resistencia criptográfica fundamental del sistema tiene una fecha de expiración que se acorta con cada avance en computación cuántica.

La desproporción es llamativa. Los mismos foros y repositorios que generan cientos de comentarios sobre OP_RETURN tienen discusiones post-cuánticas que pueden contarse con los dedos de una mano.

La gobernanza de Bitcoin es difícil por diseño. El conservadurismo del protocolo es una feature, no un bug. Pero ese conservadurismo solo funciona como virtud si el consenso conservador está informado y prioriza correctamente. Gastar capital político y técnico en disputas de política de mempool mientras se pospone indefinidamente la discusión sobre la transición criptográfica más importante en la historia del protocolo es una forma de mal uso de los recursos escasos de atención de la comunidad.

La ventana que no es infinita

Bitcoin tiene hoy una posición defensiva razonable frente a la amenaza cuántica. No está desprotegido. Pero esa protección es condicional, parcial, y no está garantizada en el tiempo.

La condición es el comportamiento correcto del usuario: no reutilizar direcciones, usar tipos de script modernos, evitar exponer claves públicas innecesariamente. Muchos usuarios no cumplen esa condición, y muchos UTXOs históricos la incumplen por diseño.

La parcialidad viene de que los outputs P2PK históricos y las claves ya expuestas no tienen defensa. Son vulnerables ahora mismo a cualquier adversario cuántico suficientemente capaz, y la única variable es cuándo ese adversario existe, no si existe.

La falta de garantía en el tiempo viene de que el protocolo no tiene todavía un camino definido hacia firmas post-cuánticas. No hay BIP en estado avanzado. No hay consenso técnico sobre qué esquema usar. No hay urgencia institucional dentro del desarrollo del core.

La computación cuántica no va a llegar un día de forma obvia y anunciada. Va a llegar incrementalmente, con cada iteración de hardware, con cada mejora en corrección de errores, con cada publicación académica que extiende el límite de lo que es atacable. El momento en que un atacante pueda usar Shor contra ECDSA-256 de forma práctica puede no ser conocido públicamente hasta después de que haya ocurrido el primer ataque.

Bitcoin sobrevivió a Mt. Gox, a los debates de block size, al silencio de su creador, a la regulación adversa de múltiples jurisdicciones, y a ciclos de mercado que destruyeron a la mayoría de sus contemporáneos. Tiene la resiliencia de un sistema que nadie controla completamente.

Pero ninguna de esas amenazas atacaba la criptografía en la que descansa la propiedad de cada satoshi. Esta sí lo hace.

La comunidad tiene tiempo. Pero tiene exactamente el tiempo suficiente para empezar ahora, y no un año más.

@benjacusu