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 чи ban: обробка цього з’єднання чекає, доки клієнт не зчитає чергу до умови відновлення. Загальна пам’ять процесу й далі містить 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, auth, частоту, розмір відповіді, timeout і maximum concurrency. Перевірте, що бібліотека читає або скасовує кожну відповідь і закриває покинуті streams. Retry має бути обмеженим і з jitter, а не миттєвим циклом. Клієнт може лишатися TCP-connected, але перестати читати, тому connect-success monitor не виявляє цю проблему.
Захистіть control plane
Прив’яжіть RPC до мінімально потрібного interface, обмежте source networks, застосуйте сильні credentials і не відкривайте сервіс напряму в Internet. Reverse proxy може обмежити connections, request rate, body size та idle time, але його правила треба перевірити на легітимних довгих відповідях. За можливості розділіть моніторинг і latency-sensitive block-template path. Під час обслуговування контролюйте templates, Stratum і miner failover. Backpressure виправляє одну чергу, а blast radius все одно визначають доступ та архітектура.
Моніторинг і тест
У staging відтворіть типові RPC/REST запити, а один тестовий клієнт змусьте читати відповіді повільно. Стежте за resident memory, open descriptors, latency, кількістю HTTP connections і здоров’ям незалежного mining client. Підтвердьте, що повільне з’єднання throttle і сервіс відновлюється після читання або disconnect. Не запускайте неконтрольований load test на production pool. Після розгортання попереджайте про тривале зростання пам’яті та latency, але не називайте коротку чергу чи одну велику відповідь атакою.
Практичний висновок
PR #36174 закриває конкретний сценарій необмеженої черги відповідей у replacement HTTP server. Для mining infrastructure варто інвентаризувати клієнтів, обмежити їхню поведінку та доступ і запланувати upgrade, коли fix увійде до підтримуваного релізу майданчика. Це не оптимізація hashrate і не має змінювати share accounting. Успіх перевіряють стабільною пам’яттю та responsive RPC у тесті slow reader, а також незмінною роботою template, pool і monitoring.
Джерело: Bitcoin Core / Bitcoin Optech ↗
Калькулятор майнінгу ↗
