Bitcoin Core ограничивает очередь HTTP-ответов backpressure на 32 MiB
Публикация источника: 2026-09-18 · Редакционный анализ опубликован: 2026-09-20
Влитый PR #36174 приостанавливает обработку запросов, когда send buffer соединения превышает 32 MiB. Операторам пулов и нод важно понимать scope, релиз и мониторинг.
Анализ и практические выводы
В этом разделе — наш анализ и условные расчёты, отдельно от сообщения источника.
Что изменилось
Bitcoin Core PR #36174 добавляет send-side backpressure в новый HTTP server проекта. В обзоре Bitcoin Optech от 18 сентября указано: клиент мог отправлять много запросов и не читать ответы, отчего очередь данных по этому соединению росла без соответствующего ограничения. Теперь обработка последующих запросов останавливается, когда send buffer соединения превышает 32 MiB, и возобновляется после чтения данных. Это дополняет receive-side защиту; consensus и вознаграждение майнера не меняются.
Почему это касается майнеров
Mining pools, template services, мониторинг и solo-mining stack часто вызывают RPC или REST Bitcoin Core. Ошибочный или зависший клиент, продолжающий заказывать данные без чтения ответов, способен расходовать память и мешать легитимному control traffic. Backpressure позволяет TCP замедлить такой клиент. Изменение не делает public RPC безопасным, не аутентифицирует клиентов и не заменяет firewall. Это дополнительная защита разрешённых интеграций и от ошибок внутри доверенной сети.
Что означает 32 MiB
32 MiB — per-connection threshold send buffer в новой логике, а не общий лимит памяти Bitcoin Core. Достижение порога не удаляет blockchain data и не банит peer: обработка этого соединения ждёт, пока клиент не прочитает очередь до условия возобновления. Общая память процесса по-прежнему включает chainstate, mempool, caches, другие соединения и OS buffers. Capacity planning должен смотреть на resident memory и число соединений, а не умножать 32 MiB на предполагаемое количество клиентов и считать результат гарантией.
Merged не означает установленный release
Pull request влит в development tree Bitcoin Core и отмечен Optech 18 сентября. Это не доказывает наличие исправления в каждом stable binary. Оператор должен определить точную версию и build commit, прочитать release notes будущего пакета и проверить его в staging. Не стоит менять воспроизводимый подписанный релиз на случайную dev-сборку ради одного fix. При срочном риске сократите доступ через reverse proxy и firewall, исправьте клиент и сохраните поддерживаемый upgrade path.
Аудит RPC-клиентов
Составьте список ПО, обращающегося к bitcoind: pool coordinators, block-template builders, explorers, payment services, metrics collectors, backup jobs и scripts. Для каждого запишите endpoint, authentication, частоту, размер ответа, timeout и maximum concurrency. Убедитесь, что библиотека читает или отменяет каждый ответ и закрывает заброшенные streams. Retry должен быть ограничен и иметь jitter, а не мгновенный цикл. Клиент может оставаться TCP-connected, но перестать читать, поэтому connect-success monitoring не выявляет этот сценарий.
Защитите control plane
Привяжите RPC к минимально нужному interface, ограничьте source networks, используйте сильные credentials и не открывайте сервис напрямую в Internet. Reverse proxy может ограничить connections, request rate, body size и idle time, но правила надо тестировать на легитимных длинных ответах. По возможности отделите monitoring traffic от latency-sensitive block-template path. Во время обслуживания наблюдайте templates, Stratum и miner failover. Backpressure исправляет одну очередь, а blast radius определяют доступ и архитектура.
Мониторинг и тест
В staging воспроизведите обычные RPC/REST запросы, а один тестовый клиент заставьте читать ответы медленно. Следите за resident memory, open descriptors, response latency, количеством HTTP connections и здоровьем независимого mining client. Подтвердите throttling медленного соединения и восстановление после чтения или disconnect. Не проводите бесконтрольный load test на production pool. После развёртывания предупреждайте о длительном росте памяти и latency, но не называйте короткую очередь или один большой ответ атакой.
Практический вывод
PR #36174 закрывает конкретный сценарий неограниченной очереди ответов в replacement HTTP server. Mining infrastructure следует инвентаризировать клиентов, ограничить их поведение и доступ и запланировать upgrade, когда fix войдёт в поддерживаемый релиз площадки. Это не оптимизация hashrate и не должно менять share accounting. Успешность проверяется стабильной памятью и responsive RPC при slow-reader тесте, а также неизменной работой block template, pool и monitoring.
Источник: Bitcoin Core / Bitcoin Optech ↗
Калькулятор майнинга ↗
