Bitcoin Core виправив збій запуску pruning із новими індексами
Публікація джерела: 2026-09-18 · Редакційний аналіз опубліковано: 2026-09-20
Merged PR #36150 не дає вузлу видалити блоки до синхронізації щойно ввімкненого індексу. Зміна є в master і ще не тотожна встановленому релізу.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Який саме збій виправлено
Pull request Bitcoin Core #36150 об’єднали з гілкою master 11 вересня 2026 року, а Bitcoin Optech звернув на нього увагу 18 вересня. Умова збою конкретна: взяти непідрізаний вузол, одночасно ввімкнути новий індекс і ціль pruning під час одного restart, після чого startup pruning спрацьовує раніше, ніж порожній індекс встановить блокування потрібних блоків. Дані могли бути видалені до початку синхронізації індексу. Patch ініціалізує prune lock на висоті genesis, якщо індекс ще не має best block, і зберігає історію для початкового індексування.
Які індекси тут важливі
Optech наводить як приклади індекс compact block filters та індекс статистики UTXO set. Перший підтримує клієнтів і сервіси, які запитують фільтри замість завантаження кожної транзакції; другий прискорює окремі запити статистики UTXO. Це функції вузла, а не керування хешрейтом ASIC, і вони не прискорюють майнінг. Зв’язок операційний: пули, solo miners, моніторинг і payout-сервіси часто залежать від надійних Bitcoin nodes. Якщо вузол не завершує startup або індекс недоступний, downstream software може втратити джерело даних, хоча парк ASIC залишається увімкненим.
Чому стара поведінка була дорогою
Коли потрібні новому індексу блоки вже видалені pruning, проста зміна параметра не відтворить їх із локального сховища. В обговоренні PR зазначено, що практичним відновленням міг бути full reindex: повторне отримання або перечитування значного обсягу chain data й очікування побудови індексу. На віддаленому майданчику це споживає bandwidth, disk I/O та час персоналу й подовжує деградацію сервісу. Bug не пошкоджував прошивки ASIC і не змінював consensus. Це проблема порядку startup усередині координації індексу й pruning, але вона могла перетворити звичайну конфігурацію на довге відновлення.
Merged code — ще не встановлений реліз
GitHub підтверджує, що зміну merged у master Bitcoin Core і пов’язано з milestone 32.0. Це не доводить, що production node вже містить її, і не слід завантажувати випадкову master-збірку заради одного fix. Перевірте фактичну версію, release notes потрібного пакета та підписаний канал дистрибуції. Якщо сьогодні треба змінити released build без patch, не вмикайте новий індекс і pruning в одному restart. Розділіть роботу так, щоб індекс завершився, поки необхідні блоки доступні, або дотримуйтеся перевіреної процедури maintainer пакета.
Плануйте зміну до роботи зі сховищем
Зафіксуйте розмір datadir, вільне місце, поточний стан pruning, активні індекси, chain tip, progress індексації та покриття backup. Оцініть час reindex на цьому hardware і network, а потім вирішіть, чи витримає maintenance window найгірший сценарій. Переконайтеся, що залежний pool або monitoring має інший здоровий node. Скопіюйте configuration та service-unit files, але не вважайте копію blockchain directory гарантовано переносним backup під час роботи вузла. Використовуйте документований shutdown і snapshot та збережіть logs точних аргументів першого restart.
Перевірка після restart
Після restart перевірте очікуваний chain tip, розумну кількість peers і progress кожного потрібного індексу без негайної помилки. Слідкуйте за disk usage та I/O, бо initial index створює тривале навантаження. Із staging client виконайте саме ті RPC, які використовує mining або payout software. Окремо перевірте block-template чи pool workflow: синхронізація індексу не доводить роботу всіх залежностей. Залиште попередній node доступним до завершення визначеного observation period. Якщо progress зупинився, збережіть logs і не змінюйте одразу кілька параметрів, щоб причина залишалася діагностованою.
Межі впливу та безпеки
PR #36150 є reliability fix для переходу конфігурації. Публічне обговорення не описує remote code execution, крадіжку коштів, invalid blocks чи consensus split. Не слід називати його критичною security vulnerability без доказів. Виправлення важливе, бо доступність node є частиною стійкості майнінгу, а невдалий storage transition може вимкнути сервіси у поганий момент. Класифікуйте інцидент точно, визначайте пріоритет за фактичним використанням pruning і нових індексів, а authentication, network segmentation, signed binaries і least privilege виконуйте за окремим планом hardening.
Що робити оператору зараз
Спочатку визначте, чи має якийсь node одночасно ввімкнути pruning і раніше відсутній індекс. Якщо ні, вузький trigger може не стосуватися плану. Далі перевірте installed release і package documentation, не припускаючи наявність master code. Потім протестуйте точний перехід на некритичному node з достатнім диском і виміряним recovery plan. Насамкінець відстежте реліз, що вперше міститиме fix, і перевірте signed checksum. Головний урок процедурний: економія storage і нові data services конкурують за ті самі історичні блоки, тому sequence і rollback evidence мають бути у change ticket.
Докази для change ticket
До change ticket додайте upstream PR, release note пакета з fix, signed checksum, статус індексів до зміни, configuration diff, прогноз диска й оцінку recovery. Після тесту додайте node logs, час завершення індексу та результати RPC production services. Запишіть, чи вдалося уникнути full reindex, а не вважайте uptime процесу доказом успіху. Так інший оператор повторить процедуру, reviewer відрізнить upstream code від package, а rollback матиме чисту основу, якщо storage behavior відрізнятиметься від canary.
Джерело: Bitcoin Core / Bitcoin Optech ↗
Калькулятор майнінгу ↗
