Bitcoin Core ha movido ficha en su política de seguridad. El equipo que mantiene la implementación de referencia de bitcoin —la que corre la mayoría de los nodos de la red— cambiará la forma de divulgar vulnerabilidades: los fallos que un modelo de lenguaje puede redescubrir con muy poco esfuerzo se parchearán cuanto antes en las versiones mantenidas y con aviso público. La lógica es incómoda pero sólida. Si una inteligencia artificial encuentra el error con una instrucción simple, el secreto ya no protege a nadie: solo retrasa la solución.
El anuncio lo trasladó Antoine Poinsot, desarrollador del proyecto, en un mensaje enviado el jueves a la lista de correo de desarrollo de Bitcoin. No hay cambio de código ni hard fork (una bifurcación que parte la red en dos versiones incompatibles). Es una decisión de procedimiento. Y en seguridad informática, el procedimiento es buena parte del blindaje.
Qué cambia exactamente en la divulgación de fallos
Hasta ahora se aplicaba lo que el sector llama divulgación responsable o coordinada: los detalles de un fallo se guardaban bajo embargo mientras se avisaba en privado a quien podía arreglarlo, y solo después, se publicaba todo, cuando la mayoría de usuarios había tenido margen para actualizar. Ese margen reducía el riesgo de que alguien explotara la brecha antes de que existiera parche. Así funciona, a grandes rasgos, la divulgación coordinada de vulnerabilidades en la industria del software.
El cálculo se ha roto por un lado inesperado. Los modelos de lenguaje grandes —los sistemas tipo ChatGPT, entrenados con volúmenes enormes de texto y código— son cada vez mejores detectando patrones en programas, y algunos fallos de bitcoin se pueden redescubrir con una consulta sencilla. Si un tercero puede llegar al mismo sitio sin esfuerzo, el embargo deja de ser una barrera y se convierte en una demora.
De ahí la nueva etiqueta: fácilmente detectables. En esos casos, Bitcoin Core corregirá el problema lo antes posible en todas las versiones principales mantenidas y publicará un aviso de seguridad junto a la actualización. El proyecto asume que el plazo largo ya no compraba protección real. El mensaje completo y el código pueden consultarse en el repositorio oficial de Bitcoin Core en GitHub.
Cuando la inteligencia artificial encuentra gratis lo que antes costaba semanas de auditoría, el secreto deja de ser un escudo y se convierte en un retraso.
Los plazos siguen dependiendo de la gravedad
El cambio no arrastra a todas las vulnerabilidades. Bitcoin Core mantiene un calendario escalonado según el daño potencial, desde errores que solo afectan a un nodo —un ordenador que guarda una copia de la blockchain y valida transacciones— hasta fallas capaces de comprometer la seguridad de la red entera.
Los errores de baja gravedad se publican dos semanas después de que aparezca la versión principal con la corrección. Los de gravedad media y alta esperan más: se hacen públicos dos semanas después de que la última versión afectada alcance su End of Life, el fin del soporte. Ese final llega, según la política descrita por el proyecto, alrededor de un año después de que el parche esté en la versión nueva. El reloj no arranca con el parche, sino con la retirada de soporte a lo antiguo.
Las vulnerabilidades críticas quedan fuera del calendario estándar. Bitcoin Core no detalla qué haría ante un fallo capaz de tumbar los fundamentos de seguridad de la red, más allá de señalar que se trataría caso por caso. Es un margen razonable y, a la vez, un reconocimiento de que hay escenarios donde ninguna plantilla funciona.
El precedente de Core Lightning y el ruido de los avisos automáticos
El ecosistema ya ha probado el cóctel. En agosto, el equipo voluntario Bitcoin Red Team reportó cerca de 5.000 posibles problemas en 390 proyectos, aunque solo alrededor de una quinta parte de esos hallazgos había sido reproducida cuando se comunicaron. La cifra impresiona. La proporción, también. No todo aviso automático es una vulnerabilidad real, y esa distinción es la que evita que la política se convierta en un sálvese quien pueda.
Ese mismo mes, los desarrolladores de Core Lightning pidieron a los operadores que actualizaran sus nodos o los desconectaran tras recibir varios informes generados con IA. Mantuvieron los detalles técnicos ocultos dos semanas, para que la información no facilitara ataques antes de que hubiera margen de reacción, y después confirmaron varias de esas fallas y prepararon un parche. El episodio dejó una lección práctica: las herramientas de lenguaje ya forman parte de la respuesta a incidentes, les guste o no a los equipos.
La actualización tampoco ha estado exenta de debate interno. Luke de Wolf, presentador de Bitcoin Infinity Show y autor de Defending Bitcoin, respaldó el cambio después de haber discrepado antes con el enfoque de Poinsot sobre seguridad. Su apoyo no altera la norma, pero indica que la comunidad técnica está reordenando prioridades: menos ceremonia con los plazos, más velocidad en la distribución de parches.
Conviene no confundir velocidad con impunidad. Publicar antes también significa dar pistas a quien busca un exploit antes de que la mayoría haya actualizado, y los parches precipitados a veces introducen errores nuevos. Ahí está la contradicción de fondo: la IA abarata el descubrimiento de fallos y, en paralelo, presiona a los equipos a moverse con menos margen de revisión. El equilibrio se parece más a un cálculo de probabilidades que a una regla cerrada.
Lo que ocurra con los operadores de nodos será la prueba de fuego. Si actualizan rápido, el nuevo calendario reduce la ventana de exposición. Si no, el aviso público servirá de mapa para quien quiera atacar versiones antiguas. Bitcoin Core ha cambiado las reglas del secreto. Ahora falta comprobar si wallets, exchanges y mineros copian el modelo o prefieren esperar a ver cómo sale la primera prueba real.
