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 filter index и индекс статистики 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 ↗
Калькулятор майнинга ↗
