Bitcoin Core fusiona correcciones del tiempo de espera RPC y las respuestas vacías
Publicación de la fuente: 2026-10-02 · Análisis editorial publicado: 2026-10-03
La rama master distingue Content-Length: 0 de una cabecera ausente y reinicia rpcclienttimeout en cada espera del socket. Es código fusionado, no un binario publicado.
Análisis e implicaciones prácticas
Esta sección contiene nuestro análisis y cálculos ilustrativos, separados del informe original.
Dos correcciones del cliente de línea de comandos alcanzaron el nivel maestro
Los mantenedores de Bitcoin Core fusionaron la solicitud de extracción 36299 en la rama maestra el 2 de octubre. El cambio contiene dos confirmaciones y modifica el cliente HTTP de línea de comandos utilizado por herramientas como bitcoin-cli. Una confirmación maneja correctamente un cuerpo de respuesta explícitamente vacío y la otra restaura el comportamiento de tiempo de inactividad previsto de rpcclienttimeout. La fusión es un evento de desarrollo de código fuente. No significa que todos los nodos o paquetes binarios de Bitcoin Core instalados ya incluyan las correcciones.
Se confundió un cuerpo vacío con un encabezado sin longitud
El cliente representó un encabezado Content-Length faltante y un encabezado presente con valor cero de la misma manera. Por lo tanto, una respuesta que declare explícitamente Content-Length: 0 podría ingresar la ruta de una respuesta sin una longitud conocida y continuar leyendo hasta que el interlocutor cierre la conexión. El servidor Bitcoin Core RPC cierra las conexiones por errores, incluida una contraseña incorrecta, lo que limitó el efecto práctico en ese caso común, pero el cliente aún debe reconocer que un cuerpo vacío está completo.
El parche preserva la distinción explícitamente.
El cambio utiliza un valor de longitud opcional, por lo que los estados ausente y presente pero cero son diferentes. Cuando el servidor envía Content-Length: 0, el cliente puede completar sin depender del cierre de la conexión. Esta es una solución de corrección del protocolo en lugar de un cambio en los métodos RPC, las reglas de billetera o el consenso de minería. Es más importante para la automatización que espera una finalización predecible del comando cuando los servidores proxy, los servidores de prueba o los puntos finales inusuales devuelven una respuesta vacía válida.
El tiempo muerto se había convertido en una cuenta atrás que abarcaba toda la fase.
Después de eliminar la implementación anterior del cliente libevent, rpcclienttimeout ya no medía solo períodos sin progreso de la red. La cuenta regresiva podría continuar durante toda una fase de lectura incluso cuando lleguen nuevos datos. Por lo tanto, a pesar de una transferencia activa, se podría interrumpir una respuesta suficientemente grande o lenta. El parche fusionado aplica el tiempo de espera a cada espera de socket, restaurando la interpretación anterior: el cliente se da por vencido después de una espera inactiva, mientras que los datos recibidos permiten otra espera programada.
Los grupos a menudo automatizan flujos de trabajo con mucho RPC
Los grupos de minería, las puertas de enlace individuales y los sistemas de monitoreo llaman a Bitcoin Core para obtener plantillas de bloques, estado de la cadena, información de mempool y envío de transacciones. Un tiempo de espera que ignora el progreso puede crear fallas falsas en respuestas grandes o enlaces lentos, mientras que el manejo ambiguo de cuerpo vacío puede retrasar el informe de errores. El cambio combinado mejora el lado del cliente de esos flujos de trabajo. No altera la salida de getblocktemplate, el comportamiento de Stratum, la validación de recursos compartidos, la prueba de trabajo o el algoritmo de dificultad de la red.
La cobertura de las pruebas difiere entre las dos confirmaciones.
La solicitud de extracción agregó una prueba para el comportamiento de respuesta vacía. El autor afirmó que no se incluyó una prueba automatizada confiable para el tiempo de espera sensible al progreso porque los enfoques intentados eran inestables o desproporcionadamente complejos. Los revisores reconocieron el enfoque y probaron el caso de respuesta vacía. La ausencia de una prueba de regresión de tiempo de espera dedicada no significa que el código no se revise, pero los operadores deben reconocer las diferentes evidencias disponibles para cada parte del parche.
Los sistemas de producción deberían esperar un lanzamiento.
La confirmación de fusión es dd809d2c08a32d0775ddde771380f6f8eeae3a61 en el maestro. Los administradores que utilicen los binarios oficiales de Bitcoin Core recibirán el cambio solo en una rama de lanzamiento y una compilación firmada que lo contenga. El maestro de construcción aumenta inmediatamente la exposición a cambios de desarrollo no relacionados. Un proceso más seguro es reproducir el comportamiento afectado en la preparación, realizar un seguimiento de los backports o notas de la versión, verificar los artefactos firmados y luego confirmar los scripts con tamaños de respuesta y retrasos de red realistas.
Qué está confirmado y qué no cambia
Los hechos confirmados son la fusión del 2 de octubre, dos confirmaciones, la distinción explícita de cuerpo vacío y el comportamiento de tiempo de espera por socket. El cambio no anuncia una versión final de Bitcoin Core, emergencia de seguridad, bifurcación de consenso o mejora del rendimiento de la minería. Su valor operativo es más limitado: comportamiento RPC de línea de comandos más confiable para respuestas vacías y que progresan lentamente. Los ingenieros del grupo también deben revisar sus propios contenedores de tiempo de espera, porque un supervisor externo aún puede finalizar un comando independientemente de la configuración de Bitcoin Core.
Fuente: Bitcoin Core ↗
Calculadora de minería ↗
