Bitcoin Core está poniendo fin a la espera de un año para parches de seguridad que un modelo de lenguaje puede encontrar nuevamente en una sola solicitud. Un cambio en la política de divulgación de seguridad del proyecto, fusionado el 22 de octubre, crea una clase de vulnerabilidad “fácilmente descubrible” e instruye a los mantenedores a lanzar una versión puntual y un aviso público “lo antes posible”, omitiendo el embargo estándar que mantiene en secreto una falla de severidad media o alta durante aproximadamente un año.
El disparador es directo. Los mantenedores están recibiendo más informes de errores que siguen siendo redescubiertos, porque los modelos de lenguaje han reducido el esfuerzo necesario para encontrarlos. Antoine Poinsot, colaborador de Bitcoin Core en Chaincode Labs, anunció el cambio en la lista de correo de Desarrollo de Bitcoin el mismo día en que se fusionó la solicitud de extracción.
“Recientemente experimentamos un aumento en la cantidad de informes sobre vulnerabilidades de seguridad que se pueden descubrir fácilmente (de nuevo)”, escribió Poinsot. “Esto se debe en gran medida a que los LLM redujeron drásticamente el umbral para encontrar ciertas clases de problemas o identificar soluciones ocultas.”
Por qué un embargo de un año detuvo la compra de cualquier cosa
La política anterior de Bitcoin Core vinculaba el momento de la divulgación con la gravedad. Los errores de baja gravedad se hacían públicos dos semanas después del lanzamiento de la siguiente versión principal. Los errores de gravedad media y alta permanecían privados hasta dos semanas después de que la última versión afectada alcanzara el fin de su vida útil — una ventana que la propia política describe como “aproximadamente un año después de que se lanzó por primera vez una versión principal que contenía la corrección”.
Ese calendario existía por una razón. Bitcoin Core es la implementación de referencia que ejecuta la mayoría de los nodos de Bitcoin, y los operadores de nodos actualizan lentamente. Se impuso un embargo prolongado para darle a la red tiempo para aplicar parches antes de hacer públicos los detalles. La compensación fue que las correcciones generalmente no se retrotraían, por lo que un operador en una versión anterior esperaba la siguiente versión principal, que el proyecto busca lanzar aproximadamente cada seis meses.
La advertencia es estructural, no accidental. Los cambios de consenso, como la actualización Taproot de bitcoin, siguen un camino lento y conservador precisamente para que los operadores los adopten según su propio calendario.
“Debido a la naturaleza de nuestro proyecto, junto con una cultura de actualización lenta, nuestra política de seguridad favorece un período de embargo más largo,” escribió Poinsot. “Esto generalmente significa que las correcciones de seguridad no se pueden backportear y solo se vuelven disponibles para los usuarios junto con el próximo lanzamiento mayor.”
La IA rompe ese compromiso. Si un error puede ser descubierto nuevamente con un escaneo trivial de un LLM, ocultarlo no aporta nada, porque la falla ya está al alcance de cualquiera que tenga un chatbot. “Para estos problemas que son fáciles de encontrar, este es el compromiso equivocado. El período de embargo logra poco, pero retrasa la disponibilidad de una versión corregida”, escribió Poinsot.
¿Qué cambia realmente la nueva clase “Fácilmente Descubrible”?
Bajo la política revisada, el reloj de divulgación ahora tiene una tercera configuración. Una vulnerabilidad puede marcarse como “fácilmente descubrible” durante la clasificación, definida como aquella que “puede descubrirse con un esfuerzo mínimo, como mediante una simple solicitud de LLM”. Esta etiqueta no se limita a errores encontrados por IA: se refiere a cuán poco esfuerzo requiere su rediscover, no a qué herramienta realizó el hallazgo.
Para esos errores, la respuesta varía en cada eje. En lugar de una sola corrección que se incluya en la próxima versión principal, los mantenedores backportearán una corrección a cada versión principal actualmente mantenida —tres ramas bajo la regla de Bitcoin Core de respaldar sus tres lanzamientos más recientes— y lanzarán versiones puntuales lo más rápido posible. Un aviso de seguridad se publicará junto con el software corregido.
La escalera de gravedad sigue gobernando todo lo demás. Los errores de baja gravedad permanecen en el calendario de dos semanas. Los de media y alta gravedad permanecen en el reloj de aproximadamente un año. Los errores críticos —aquellos que podrían robar monedas a nivel de protocolo, inflar la oferta o dividir permanentemente la cadena— siguen fuera de la política estándar y se manejan caso por caso, como siempre lo han sido.
Esa exclusión existe por una buena razón. En la historia de Bitcoin Core, el bug de inflación divulgado como CVE-2018-17144 en septiembre de 2018 fue el tipo de falla que justificaba un manejo especial: podría haber permitido la creación de monedas fuera del calendario de emisión. La nueva ruta “fácilmente descubrible” no toca ese nivel: un bug crítico seguirá recibiendo una respuesta ad hoc adaptada al riesgo para toda la red.
Dos semanas, un año o “lo antes posible”
La variación es más fácil de leer como una reducción en la ventana de divulgación. Un error de gravedad media corregido hoy normalmente permanecería privado durante aproximadamente 52 semanas, divulgado solo dos semanas después de que la última versión afectada alcanzara el fin de su vida útil. El mismo error, una vez marcado como fácilmente descubrible, se distribuye como una versión puntual “lo antes posible” junto con su advertencia. Esa es la diferencia entre un año y, en la propia formulación de los mantenedores, el tiempo que tome escribir, revisar y probar un parche específico.
El compromiso de backport es la otra mitad. Antes del cambio, una corrección generalmente no llegaba a los usuarios en una rama mantenida más antigua; llegaba con la siguiente versión principal. Ahora, un operador en una versión compatible más antigua puede aplicar una liberación puntual específica sin adoptar todas las funciones y cambios de comportamiento de la versión principal más reciente. Para una red donde las actualizaciones son lentas y deliberadas, esto representa un cambio significativo en la rapidez con la que realmente puede aplicarse un parche.
El riesgo que los mantenedores mismos señalaron
La ruta más rápida tiene un costo, y Poinsot lo dijo claramente en la solicitud de extracción. “Esto es particularmente importante porque, bajo esta política, las mitigaciones no tendrán tanto ‘tiempo de cocción’ en las ramas de desarrollo antes de ser liberadas a los usuarios”, escribió. Una corrección que se implementa en días pasa menos tiempo en revisión y pruebas que una que permaneció durante meses.
La discusión también se dividió sobre si la divulgación debería ser aún más rápida. Algunos colaboradores argumentaron que abrir una solicitud de extracción de una corrección puede alertar a los atacantes, ya que es económico observar automáticamente el repositorio, por lo que la divulgación podría necesitar realizarse no más tarde que el parche, o incluso antes, junto con orientación de mitigación. Otro colaborador propuso implementar correcciones con un aviso discrecional o retrasado. Poinsot rechazó esa idea, escribiendo que alertar a los usuarios sin detalles podría desencadenar una migración apresurada entre operadores que nunca fueron afectados.
El exchange importa porque muestra que la nueva política es un camino intermedio deliberado, no uno obvio. El texto combinado mantiene el aviso simultáneo con la corrección y conserva todos los detalles, en lugar de una advertencia vaga.
Cuando aterrice el primer error “fácilmente detectable”
Aún no se ha asignado ninguna vulnerabilidad a la nueva clase, por lo que se trata de un cambio en el proceso, no de la divulgación de una falla activa. La primera prueba real llegará cuando los mantenedores marquen algo como “fácilmente descubrible” durante la clasificación y publiquen lanzamientos de puntos en todas las ramas mantenidas junto con un aviso simultáneo.
La señal más amplia es que la búsqueda de errores asistida por IA ya ha obligado al ecosistema de bitcoin a moverse. Core Lightning le pidió a los operadores de nodos a principios de este año que actualicen o desconecten después de que los informes de vulnerabilidades generados por IA demostraran ser correctos. El cambio de política de Bitcoin Core es la implementación de referencia que realiza el mismo cálculo en la capa base del protocolo: cuando el redescubrimiento es económico, el secreto compra poco, y lo único que retrasa un embargo prolongado es el lanzamiento fijo.
Para los operadores de nodos, hoy no cambia nada. La frecuencia de actualización permanece igual. La diferencia se produce la próxima vez que un error califique como fácilmente detectable, cuando un parche y su aviso se implementen juntos con menos advertencia de la que la red haya tenido nunca.
Descargo de responsabilidad: Este artículo no constituye asesoramiento de inversión. El contenido y los materiales presentados en esta página son únicamente con fines educativos.