-
Las estimaciones de BTC expuesto a la computación cuántica van de 25% a más de 34%.
-
El análisis incluye un nivel de riesgo para distintos tipos de direcciones de Bitcoin.
Un desarrollador identificado como duncan0k propuso esta semana en el foro Delving Bitcoin un estándar para determinar qué salidas de Bitcoin son vulnerables a un ataque de computación cuántica.
La discusión, abierta el 3 de septiembre y todavía activa, responde a un vacío que BIP-360 y BIP-361 dan por resuelto sin especificarlo: qué monedas cuentan como expuestas y qué debería hacer cada wallet con ellas.
El problema no es menor porque las cifras publicadas ni siquiera coinciden entre sí. Duncan sostiene, en el borrador de clasificación que acompañó su publicación, que las estimaciones de suministro expuesto oscilan entre 25% y más de 34% del total en circulación. Estamos hablando de más de 6 millones de BTC vulnerables. Sin embargo la brecha es definicional, no de medición.
Las herramientas no coinciden en si una salida Taproot cuenta como expuesta en reposo, ni en cómo tratar un P2SH cuyo script nunca se reveló en cadena. Duncan remite esa lectura de Taproot a una discusión previa sobre los cambios a BIP-360, donde ya se había planteado el mismo problema.
Ahí aparece la tesis de fondo de esta discusión: el debate poscuántico en Bitcoin ya dejó de ser sobre qué firma adoptar. Antes de decidir eso hace falta un criterio común para clasificar lo que ya existe. Esa es la laguna que los desarrolladores de Bitcoin intenta cerrar, porque cualquier migración a gran escala va a preguntar lo mismo, con dinero real de por medio, desde programas que deberían responder igual sin importar quién los escribió.
La propuesta resuelve esa ambigüedad con cuatro categorías, más una tabla de asignación según el tipo de salida:
- Expuesta en reposo: la clave pública ya es visible en cadena, sin necesidad de gastar la moneda (P2PK, direcciones reutilizadas, Taproot).
- Expuesta al gastar: la clave solo se revela en el momento de la transacción (P2PKH y P2WPKH sin reutilizar).
- No expuesta: la clave pública nunca quedó visible en la cadena de bloques.
- Indeterminada: los datos disponibles no alcanzan para clasificar la salida con certeza.
La regla que sostiene esta tabla es deliberadamente conservadora: cuando los datos no alcanzan para distinguir entre dos niveles, se asigna siempre el más expuesto de los dos, nunca el más optimista.
Qué debería hacer una wallet con cada nivel
La primera versión del borrador se limitaba a clasificar salidas, sin decir qué hacer con esa información. Un desarrollador de wallets que participa en el hilo bajo el nombre Anzus_GemWallet señaló el hueco: sin una acción recomendada estándar, cada wallet mostraría advertencias distintas para la misma situación ante el mismo tipo de salida.
Duncan aceptó la objeción, pero trazó una línea que vale la pena remarcar. Calcular el riesgo real de una dirección —cuánto saldo tiene, cuánto tiempo lleva inactiva, cuándo podría existir una computadora cuántica capaz de romperla— es subjetivo y no se puede leer en la cadena de bloques. La acción mínima, en cambio, sí se deduce casi mecánicamente de cada nivel.
Esa distinción quedó plasmada en la versión 0.4.0 del borrador, publicada el 14 de septiembre:
| Nivel | Acción mínima | Qué significa |
|---|---|---|
| Expuesta en reposo | MIGRATE | Mover el saldo apenas exista un destino confiable |
| Expuesta al gastar | SWEEP_WHEN_SPENDING | Vaciar todo al gastar, sin recibir cambio de vuelta |
| No expuesta | NONE | Sin acción requerida |
| Indeterminada | TREAT_AS_MIGRATE | Tratarla como expuesta en reposo hasta poder clasificarla |
Las wallets pueden agregar matices sobre esa base, pero no pueden contradecir ese mínimo.
Lo que esta propuesta resuelve antes de que haga falta
El detalle que distingue a este borrador de otras discusiones sobre criptografía postcuántica es el momento en que llega. BIP-360 todavía no activa, no existe consenso sobre qué firma postcuántica adoptará Bitcoin y nadie ha construido una computadora cuántica capaz de romper una clave pública. Duncan no está resolviendo un problema técnico urgente: está resolviendo un problema de coordinación que todavía no se manifestó, pero que se volverá crítico el día en que sí lo haga.
Eso es, en el fondo, lo que separa a Bitcoin de una migración impuesta desde arriba. Si el día de una amenaza real cada wallet tuviera su propio criterio para decidir qué salida está en riesgo, la reacción del ecosistema sería caótica:
- Unas wallets alertarían a tiempo; otras no.
- El usuario común no tendría forma de saber en cuál criterio confiar.
- Direcciones idénticas recibirían tratamientos distintos según el software usado.
Un estándar acordado de antemano, aunque parezca prematuro hoy, es lo que permite que millones de wallets independientes respondan de forma coherente sin que nadie tenga que ordenarlo.
Ahí está la conclusión menos evidente de este hilo: la objeción de murch, investigador y desarrollador de Bitcoin Core, quien calificó la clasificación de trivial, no contradice ese valor sino que lo confirma. Que una tabla parezca obvia para un desarrollador de Bitcoin Core no significa que sea innecesaria; significa que el ecosistema todavía no pagó el costo de no tenerla. Ese costo aparece recién cuando dos wallets, ante la misma dirección, dan una respuesta distinta y el usuario pierde fondos por seguir la equivocada.
Esta discusión también expone quién asume el riesgo de una migración postcuántica y quién no. Las direcciones expuestas en reposo —P2PK originales y P2PKH reutilizadas con saldo— son en su mayoría carteras antiguas, muchas inactivas desde hace años, entre ellas las atribuidas a Satoshi Nakamoto. Nadie puede obligar a esas monedas a moverse.
El estándar de Duncan no cambia eso. Solo garantiza que, si algún día su dueño decide actuar, o si la red decide congelarlas mediante algo como la fase C de BIP-361, exista un criterio común para identificarlas sin ambigüedad.
Un estándar que Bitcoin Core no ve necesario
En la discusión, algo latente es que no todo el foro está convencido de que esto merezca convertirse en BIP. Murch, un desarrollador con peso reconocido en Bitcoin Core, respondió sobre el final del hilo en Delving Bitcoin que la clasificación le parece trivial como para justificar un BIP propio, sin desarrollar más el argumento hasta el momento de escribir esta nota.
Esa objeción no invalida el trabajo técnico, pero sí expone una tensión que atraviesa buena parte del desarrollo de Bitcoin: la diferencia entre un comportamiento que todo el software debería compartir y uno que amerita quedar fijado en un documento normativo. Un detalle de implementación que cada wallet resuelve a su manera es justamente el escenario que Duncan quiso evitar desde el primer mensaje del hilo.
Lo que queda claro, más allá de si termina siendo BIP o convención de facto entre wallets, es que nadie está proponiendo forzar una migración. Bitcoin no tiene una autoridad central capaz de reetiquetar carteras ajenas ni de mover fondos que no le pertenecen. Lo único que este estándar hace posible es que, cuando ese momento llegue, cada usuario reciba la misma advertencia sin importar qué wallet use. La decisión de moverse o quedarse, como siempre en Bitcoin, sigue en manos de quien controla las claves.
