Bitcoin Core 32.0 entra en la fase final antes de su lanzamiento previsto el 10 de octubre

Bitcoin Core 32.0 llega al final de un ciclo de desarrollo donde los cambios más visibles no son necesariamente los más interesantes. La versión candidata ya está disponible y los desarrolladores apuntan al 10 de octubre para la versión final. En el menú: validación mejor organizada, servidor HTTP revisado y varios parches de seguridad. Una auditoría asistida por IA también ha iniciado una secuencia de pruebas bastante instructiva: el primer diagnóstico aún no había contado toda la historia.

En breve

• Bitcoin Core 32.0 se acerca a su lanzamiento tras varios meses de desarrollo, con una versión candidata ahora sometida a las últimas pruebas de los colaboradores.
• La validación de bloques evoluciona bajo el capó gracias a la carga paralela de ciertos datos, especialmente útil para los operadores que ejecutan sus propios nodos.
• Kimi K3 ayudó a detectar una debilidad en el servidor HTTP, antes de que un desarrollador descubriera que el escenario podía afectar a más conexiones.
• El parche en sí requirió varios ajustes, ya que su primera versión protegía la memoria mientras introducía una latencia molesta en algunas conexiones persistentes.
• Para el usuario común, el cambio seguirá siendo en gran medida invisible, mientras que los desarrolladores y operadores se beneficiarán principalmente de una infraestructura mejor protegida y más eficientemente organizada.

Bitcoin Core 32.0 acelera principalmente el trabajo bajo el capó

Bitcoin Core permite a una computadora verificar por sí misma las transacciones y bloques de la red, sin tener que delegar esta tarea a un servicio externo. La versión 32.0 afecta principalmente a los operadores de nodos, desarrolladores y servicios construidos alrededor de esta infraestructura.

El cambio de rendimiento más notable se refiere a la validación de bloques. Para verificar una transacción, el software debe encontrar las salidas anteriores que gasta, los famosos prevouts. Cuando se encuentran en disco, su lectura puede ralentizar el trabajo. La nueva versión permite precargar estos datos en paralelo desde la base chainstate.

Ocho hilos trabajan por defecto, con un máximo fijado en dieciséis. Una máquina más modesta podrá reducir este número a cero y desactivar el mecanismo.

La ganancia no hará que la blockchain sea más rápida ni reducirá el intervalo entre dos bloques. Se refiere al trabajo realizado localmente por el nodo. Una matiz técnica, ciertamente discreta en la pantalla, pero bastante concreta para aquellos que mantienen la infraestructura día tras día.

Kimi K3 detecta una falla, los desarrolladores investigan más a fondo

La historia comienza con Matthew Zipkin, un colaborador conocido bajo el seudónimo pinheadmz. Al auditar el nuevo servidor HTTP con Kimi K3, un modelo de inteligencia artificial también empleado por el Bitcoin Red Team, se encuentra con un escenario de agotamiento de memoria.

El servidor podía seguir leyendo los datos enviados por un cliente mientras ya estaba procesando una solicitud. Un cliente malicioso tenía así la posibilidad de mantener esta solicitud ocupada y luego enviar cada vez más datos. Estos se acumulaban en la memoria.

Zipkin pensó primero que el ataque requería autenticación. Luego, la revisión del código cambió el panorama. El desarrollador jeanpablojp prueba la interfaz REST y observa que 16 conexiones sin credenciales pueden hacer que el consumo del nodo pase de aproximadamente 46 MB a casi 3 GB en un minuto.

La IA había detectado correctamente un problema. No había cerrado la investigación. Un humano llevó la prueba más lejos y descubrió un vector más amplio. Esta es una colaboración hombre-máquina mucho más interesante que un simple partido para ver cuál de los dos encuentra más errores.

El primer parche ralentizaba demasiado el servidor

La primera respuesta de Zipkin seguía una lógica bastante sobria: cuando una solicitud ya está siendo procesada, no es necesario seguir absorbiendo los siguientes datos en la memoria de la aplicación. Pueden esperar del lado del sistema hasta que la presión TCP frene naturalmente al remitente.

La solución de este parche consiste en no leer el socket cuando estamos ocupados procesando una solicitud.

Matthew Zipkin, GitHub PR #36123

Sin embargo, el primer parche tenía un defecto. En una conexión persistente, jeanpablojp mide una latencia media que pasa de aproximadamente 0,14 ms a 53 ms. El parche protegía la memoria, pero hacía esperar innecesariamente a algunas solicitudes.

Nueva copia, nuevas pruebas. Después de la revisión, 16 conexiones REST no autenticadas solo añaden aproximadamente 3 MB en 90 segundos, frente a 3,2 GB anteriormente. La penalización de aproximadamente 50 ms también desaparece.
Tus primeras criptos con Binance Este enlace utiliza un programa de afiliación

No todo es gratuito. En un nodo inactivo sometido a un pipelining continuo, un revisor mide un rendimiento que pasa de 383 a 18,9 solicitudes por segundo. Un caso muy específico, que dice no encontrar en ningún cliente real. La seguridad gana, por lo tanto, claramente la apuesta, con un compromiso medido en lugar de oculto.

En octubre, los operadores encontrarán sobre todo limpieza útil

La versión 32.0 no se resume a esta historia de memoria. Varios cambios menos espectaculares llegarán con ella si el calendario se mantiene. Cuatro comandos relacionados con transacciones parcialmente firmadas utilizarán PSBT v2 por defecto. Las aplicaciones que lo necesiten aún podrán solicitar la versión anterior.

El servidor HTTP, por su parte, ha sido reescrito para reemplazar libevent. Aplica reglas más estrictas y limita por defecto a dieciséis el número de clientes HTTP conectados simultáneamente. Otro ahorro apreciable: después de la reconstrucción, el índice de transacciones txindex ocupará menos de la mitad de su antiguo espacio en disco.

En el lado de la billetera, exportwatchonlywallet permitirá exportar la información necesaria para una billetera de observación sin llevar las claves privadas.

Un parche también cierra la vulnerabilidad walletnotify. En sistemas que no son Windows, un usuario RPC autenticado con los derechos necesarios podía crear ciertos nombres de billeteras para provocar la ejecución de comandos. Estos nombres ahora se tratan literalmente.

Para el usuario de una aplicación ligera, nada de esto altera el día. Para aquellos que ejecutan nodos de blockchain, los detalles cuentan más.

A tener en cuenta antes del 10 de octubre

• La salida de Bitcoin Core 32.0 está prevista para el 10 de octubre de 2026, una fecha que sigue siendo susceptible de cambiar durante las últimas pruebas de la versión candidata.
• La validación podrá precargar ciertos datos con ocho hilos por defecto y dieciséis como máximo, sin modificar la cadencia de producción de bloques.
• Después de la corrección, 16 conexiones REST no autenticadas añadían aproximadamente 3 MB de memoria en 90 segundos, frente a 3,2 GB antes de la revisión.
• Cuatro comandos de billetera adoptarán PSBT v2 por defecto, mientras que las aplicaciones conservarán la posibilidad de solicitar la versión anterior.
• Un txindex completamente reconstruido ocupará menos de la mitad del espacio en disco, mientras que el nuevo servidor HTTP recibe varias salvaguardias adicionales.

El calendario ofrece, además, un bonito cruce. Mientras Bitcoin Core apunta a octubre, Ethereum prepara Glamsterdam, la próxima evolución importante de su blockchain. Sepolia debe acoger una prueba el 6 de octubre, si se corrigen los errores aún presentes en los devnets. Se espera que el mainnet llegue en el cuarto trimestre, con diciembre aún como una posibilidad. Dos proyectos diferentes, un mismo método: probar, romper a veces, corregir mucho y luego solo entregar.