Bitcoin Core limita respuestas HTTP en cola con backpressure de 32 MiB
Publicación de la fuente: 2026-09-18 · Análisis editorial publicado: 2026-09-20
El PR #36174 detiene solicitudes cuando el buffer de envío de una conexión supera 32 MiB. Operadores de pools y nodos deben entender alcance, despliegue y monitorización.
Análisis e implicaciones prácticas
Esta sección contiene nuestro análisis y cálculos ilustrativos, separados del informe original.
Qué cambió
Bitcoin Core PR #36174 añade backpressure de envío al nuevo HTTP server del proyecto. El resumen de Bitcoin Optech del 18 de septiembre explica que un cliente podía emitir muchas solicitudes sin leer respuestas y hacer crecer la cola de salida de esa conexión sin límite equivalente. Ahora se detienen más solicitudes cuando el send buffer supera 32 MiB y se reanudan tras drenarlo. Complementa un control previo de recepción; corrige gestión de recursos en el servidor nuevo y no cambia consensus ni recompensas mineras.
Por qué interesa a mineros
Pools, servicios de plantillas, monitorización y sistemas de solo mining suelen usar RPC o REST de Bitcoin Core. Un cliente defectuoso o bloqueado que solicita datos sin consumir respuestas puede gastar memoria y competir con control traffic legítimo. Backpressure permite que TCP frene ese cliente. El cambio no hace seguro un RPC público, no autentica clientes y no sustituye el firewall. Es defensa adicional para integraciones autorizadas y errores dentro de una red confiable.
El umbral de 32 MiB
32 MiB es un threshold por conexión para el send buffer de la nueva lógica, no un límite global de memoria de Bitcoin Core. Alcanzarlo no elimina blockchain data ni banea al peer; se pausa esa conexión hasta que el cliente drena suficiente salida. La memoria total incluye chainstate, mempool, caches, otras conexiones y buffers del sistema. Capacity planning debe observar resident memory y conexiones, no multiplicar 32 MiB por un número supuesto y tratarlo como garantía.
Código merged no es release instalado
El pull request se fusionó en el development tree y Optech lo destacó el 18 de septiembre. Eso no prueba que todos los stable binaries lo incluyan. Identifique versión y build commit, lea release notes de la futura versión empaquetada y pruebe en staging. No cambie una versión firmada y reproducible por una dev build arbitraria para obtener una corrección. Si la exposición es urgente, redúzcala con reverse proxy, firewall y cambios del cliente mientras conserva una ruta soportada.
Auditar consumidores RPC
Inventaríe software que habla con bitcoind: coordinadores, block-template builders, explorers, pagos, métricas, backups y scripts. Para cada uno registre endpoint, autenticación, frecuencia, tamaño, timeout y concurrencia. Confirme que la biblioteca lee o cancela cada respuesta y cierra streams abandonados. Los retry deben ser limitados y con jitter. Un cliente puede seguir TCP-connected pero dejar de leer, por lo que comprobar solo la conexión no detecta la condición objetivo.
Proteger el control plane
Vincule RPC a la interfaz mínima, limite source networks, use credenciales fuertes y no exponga directamente a Internet. Un reverse proxy puede limitar conexiones, request rate, body size e idle time, pero debe probarse con respuestas legítimas largas. Separe monitorización de rutas sensibles de block template cuando sea posible. Observe templates, Stratum y miner failover durante mantenimiento. La corrección mejora una cola, mientras acceso y arquitectura siguen determinando el blast radius.
Prueba y monitorización
En staging reproduzca RPC/REST representativos mientras un cliente de prueba lee despacio. Observe resident memory, open descriptors, latency, conexiones HTTP y un mining client independiente. Confirme que la conexión lenta queda throttled y que el servicio se recupera al drenar o desconectar. No haga un load test sin control en un pool de producción. Tras desplegar, alerte por crecimiento sostenido de memoria y latencia, sin confundir una cola breve o respuesta grande con un ataque.
Conclusión operativa
PR #36174 cierra un comportamiento concreto de cola de respuestas sin límite en el replacement HTTP server. La acción para infraestructura minera es inventariar clientes, limitar comportamiento y acceso y planificar upgrade cuando la corrección llegue a la versión soportada. No optimiza hashrate ni debe cambiar share accounting. El éxito se mide con memoria estable y RPC responsive bajo una prueba slow reader, además de plantillas, pool y monitorización sin regresiones.
Fuente: Bitcoin Core / Bitcoin Optech ↗
Calculadora de minería ↗
