Bitcoin Core integra una corrección de macOS para bitcoin-cli con tiempo de espera ilimitado
Publicación de la fuente: 2026-10-07 · Análisis editorial publicado: 2026-10-07
El PR #36340 se integró el 7 de octubre. Limita la espera del socket usada por -rpcclienttimeout=0; su inclusión en un lanzamiento o backport debe comprobarse por separado.
Análisis e implicaciones prácticas
Esta sección contiene nuestro análisis y cálculos ilustrativos, separados del informe original.
La fusión de hoy soluciona un problema operativo del lado del cliente
Bitcoin Core fusionó la solicitud de extracción #36340 el 7 de octubre a las 07:27:37 UTC, según la API oficial de GitHub. El cambio soluciona un error de conexión de macOS que involucra bitcoin-cli con -rpcclienttimeout=0. Verificamos el estado actual de la API y cambiamos los archivos porque la página web almacenada en caché todavía mostraba un estado abierto anterior. Un cambio de desarrollo fusionado es el evento confirmado. No establece que una versión empaquetada en particular, un repositorio de sistema operativo o un firmware de minero en particular ya contenga la corrección.
La relevancia para la infraestructura minera es el cliente de línea de comandos utilizado para comunicarse con un nodo. Un comando fallido puede interrumpir la supervisión o el flujo de trabajo administrativo incluso cuando el nodo se está ejecutando. Nuestra interpretación es que esta noticia pertenece a la confiabilidad del software, y su alcance se mantiene separado del desempeño de la minería. No es un nuevo modo de ajuste de ASIC, un cambio en la prueba de trabajo o una afirmación de que los dispositivos enviarán más hashes aceptados después de la instalación. El componente afectado y la ruta del código real deben permanecer explícitos.
El cero en una capa puede convertirse en un número grande en otra
La solicitud de extracción explica que la configuración sin tiempo de espera documentada del cliente está representada internamente por una duración muy larga. Ese valor luego llega a la implementación de socket-wait. Nuestro análisis es que este es un límite entre una opción orientada al usuario y el sistema operativo primitivo que la implementa. Una opción descrita como ilimitada aún puede traducirse en un valor finito mediante software. Si la API de nivel inferior no puede aceptar ese valor, el comando puede fallar por razones que el nombre de la opción visible no hace evidente.
Esta distinción ayuda a explicar por qué un error de conexión no siempre prueba que un nodo esté fuera de línea o que sus credenciales sean incorrectas. Un programa puede rechazar un parámetro local antes de que se complete el intercambio esperado. Los operadores deben distinguir la resolución de nombres, el establecimiento de la conexión, la autenticación, el procesamiento de solicitudes y la espera de respuesta al interpretar un error. Estos son límites de diagnóstico generales, no un informe de que todos ellos sean defectuosos en Bitcoin Core. Aquí la fuente identifica un valor de espera de gran tamaño, por lo que el análisis se centra en ese mecanismo.
El parche final limita la espera subyacente
La evidencia actual del archivo modificado muestra un límite aplicado en Sock::WaitMany y una verificación funcional para la opción de cliente de tiempo de espera cero. El código utiliza el valor máximo de milisegundos con signo int, aproximadamente 24,8 días, para una espera limitada individual. Esto no debe reescribirse como espera infinita nativa recientemente implementada. Las discusiones anteriores consideraron un enfoque separado, pero el cambio final inspeccionado mantiene un límite. Nuestra cobertura sigue el código fusionado real en lugar de una propuesta intermedia en la conversación.
La conversión de unidades es importante: los milisegundos y los segundos difieren en un factor de 1000. Un valor de tiempo de espera pasado a través de varias capas puede adquirir límites diferentes según la representación que acepte cada capa. Este es un problema de interfaz de software, no un cálculo de electricidad o hashrate de red. Nuestra interpretación es que el uso de una duración representable evita la falla inmediata identificada en el informe y deja la semántica más amplia del tiempo de espera como un tema separado. Los lectores no deben deducir una garantía operativa ilimitada de la duración aproximada del límite.
El estado del repositorio y el software publicado son hechos separados
Una combinación registra que el repositorio de desarrollo aceptó un cambio. La distribución a los usuarios puede realizarse mediante un lanzamiento, un backport o una actualización de paquete, cada uno con su propio calendario. Nuestro análisis no asigna la solución a una versión descargable numerada sin verificar su contenido. La API principal proporciona una confirmación de fusión que se puede utilizar para rastrear el cambio. Un usuario que decida si desea actualizar debe comparar la versión instalada real y la información de versión relevante en lugar de confiar únicamente en la fecha de este artículo.
Esta distinción es particularmente útil para infraestructura que intencionalmente permanece en una rama estable. Una corrección en la rama de desarrollo no significa que todos los paquetes estables hayan cambiado. Una etiqueta o discusión del backport tampoco prueba que el backport se haya fusionado y enviado. Por lo tanto, nuestra cobertura trata el seguimiento planificado por separado de la inclusión verificada. La siguiente evidencia útil es la documentación de liberación o confirmación de rama correspondiente, con una declaración clara de qué compilación necesitaría un operador para obtener la corrección.
Una solución anterior relacionada abordó una parte diferente del cliente.
ASIC.tools cubrió anteriormente cambios en respuestas vacías y manejo del tiempo de espera del cliente RPC en otra solicitud de extracción. El nuevo elemento es una corrección fusionada separada del gran valor pasado a la espera del socket, en lugar de una republicación de ese evento anterior. Nuestra lectura es que las dos capas pueden afectar el mismo flujo de trabajo del usuario al tiempo que abordan mecanismos diferentes. El registro de la solicitud de extracción y la fecha de fusión mantiene identificable el nuevo desarrollo y evita presentar una nota de versión antigua como un anuncio nuevo.
Para los mantenedores, esta separación hace que el informe de regresión sea más preciso. Un síntoma que persiste después de una actualización puede requerir examinar la implementación de espera de nivel inferior en lugar de asumir que la corrección anterior nunca se instaló. También evita atribuir cada error del lado del cliente a un único parche. La revisión práctica sigue el error, la opción suministrada, el sistema operativo y el binario exacto. Esos detalles son más informativos que una declaración general de que se corrigió RPC, lo que puede implicar un alcance más amplio que el que realmente tiene cualquiera de los cambios individuales.
Una verificación local debería establecer el comportamiento sin cambiar la configuración de minería
Para un operador afectado por este problema, una solicitud de cliente de solo lectura controlada puede ayudar a distinguir una falla de un cliente local de un problema de nodo. La prueba exacta debe coincidir con la versión instalada y la configuración del nodo autorizado. Nuestro análisis favorece capturar el resultado del comando, la versión del cliente y el error observado antes de cambiar configuraciones no relacionadas. Una prueba de conectividad no requiere cambiar una billetera, un servidor del pool, la frecuencia del dispositivo o la configuración de enfriamiento, y este cambio de código no proporciona evidencia de que esos ajustes resolverían el límite de tiempo de espera identificado.
Una solicitud corta exitosa muestra que un intercambio particular se completó bajo las condiciones probadas. No prueba que todas las solicitudes de larga duración se mantengan saludables indefinidamente. El monitoreo aún debe registrar las interrupciones y el comportamiento de recuperación. Estas son consideraciones operativas independientes en lugar de afirmaciones de pruebas realizadas por ASIC.tools en todas las plataformas compatibles. Verificamos la fuente y la diferencia final; No hemos reproducido el error en todas las versiones de macOS ni hemos publicado una matriz de compatibilidad certificada de forma independiente.
Más reintentos pueden ocultar el motivo por el que falló una solicitud
Un sistema de automatización puede reintentar una solicitud fallida, pero el reintento no sustituye la identificación de la capa del error. El envío repetido del mismo parámetro de espera localmente no válido puede producir errores repetidos. Nuestra interpretación es que un operador debe distinguir las fallas antes de que se acepte una solicitud de los resultados inciertos después de la presentación. Esa distinción importa más allá de este error específico porque algunas llamadas RPC administrativas cambian de estado, mientras que otras solo lo leen. Un resultado incierto debe conciliarse antes de que se repita una acción que cambie el estado.
Este artículo no afirma que la corrección del tiempo de espera fusionada cambie la política de transacciones o haga que cada llamada RPC sea segura para repetir. Aborda un comportamiento de conexión. La lección operativa general es registrar suficiente información para decidir si la solicitud llegó al servidor y si se conoce su resultado. Un diagnóstico de solo lectura puede proporcionar evidencia sin introducir operaciones duplicadas. Mantener esa disciplina en el monitoreo y las herramientas administrativas hace que una pequeña solución de confiabilidad del cliente sea más útil que tratarla como una razón para aumentar el número de reintentos sin investigar.
Qué cambios para los lectores de ASIC.tools
La actualización confirmada es una corrección fusionada del lado del cliente, respaldada por la API del repositorio oficial y archivos modificados inspeccionados. Su fecha es la fecha de fusión de hoy, distinta de la fecha anterior en la que se abrió la solicitud de extracción. No se ha reasignado ningún binario ASIC a raíz de esta noticia. La fuente de Bitcoin Core está vinculada para los lectores que desean inspeccionar el cambio final, y el registro de investigación almacenado incluye la evidencia API utilizada para resolver el estado obsoleto mostrado por la página web.
La conclusión práctica es mantener separados el comportamiento del cliente, el estado del nodo y la configuración del dispositivo de minería al investigar una falla de monitoreo. Los operadores que encuentren este problema exacto con la opción macOS pueden seguir la evidencia de lanzamiento o backport antes de elegir una actualización y luego verificar el comportamiento del binario instalado real. El artículo evita prometer una ganancia de hashrate o afirmar que ya se ha enviado una fusión de desarrollo. Sus fotografías son ilustraciones contextuales de informática e infraestructura, no capturas de pantalla ofrecidas como prueba del comportamiento del software corregido.
Fuente: Bitcoin Core / GitHub ↗
Calculadora de minería ↗
