Ветка Bitcoin Core 32.x перешла к третьему релиз-кандидату
Публикация источника: 2026-10-01 · Редакционный анализ опубликован: 2026-10-02
Версию rc3 и обновлённую документацию объединили 1 октября после 29 коммитов с rc2. Операторам следует дождаться подписанных официальных бинарников и считать кандидат тестовым ПО.
Анализ и практические выводы
В этом разделе — наш анализ и условные расчёты, отдельно от сообщения источника.
Ветка 32.x теперь идентифицируется как rc3.
1 октября сопровождающие Bitcoin Core объединили запрос на извлечение 36400, переведя ветку 32.x на версию 32.0rc3. Сам запрос на включение содержит три коммита: обновление версии, восстановленные страницы руководства и восстановленный пример bitcoin.conf. Он изменил девять файлов и был объединен как коммит 2633a1de. Это важный этап подготовки выпуска в системе контроля версий, а не объявление о том, что финальная версия Bitcoin Core 32.0 доступна.
Кандидат на выпуск создается для тестирования.
В документации жизненного цикла Bitcoin Core объясняется, что кандидаты на выпуск используют суффиксы rc, такие как rc1, rc2 и rc3. Они предоставляют разработчикам, операторам узлов и последующим упаковщикам почти финальную сборку для тестирования перед выпуском стабильного основного выпуска. Более высокий номер rc сам по себе не означает одобрения производства. Это означает, что другой кандидат был подготовлен после изменений или исправлений, и тестирование все равно может выявить причины для rc4 или дополнительной работы.
Ветка на 29 коммитов опережает тег rc2.
Сравнение GitHub v32.0rc2 с веткой 32.x показало 29 коммитов на момент проверки. К ним относятся код, тесты, документация, корректировки сборки и коммиты для создания версии rc3. Подсчет коммитов не является мерой серьезности: небольшое оперативное исправление может иметь большее значение, чем несколько обновлений документации. Операторам следует прочитать окончательные примечания к выпуску и изучить конкретные подсистемы, которые они используют, а не делать вывод о риске только на основании количества.
Кандидат несет несколько операционных корректировок
Изменения между rc2 и текущей веткой включают в себя резервные средства оценки комиссий, очистку статистики добытых блоков, когда состояние мемпула не может быть загружено, удаление обратных вызовов комиссии перед сохранением состояния отключения, формулировку, которая отмечает экспериментальную частную трансляцию, и категорию отладки майнинга для повторяющегося журнала шаблона блока. Каждое изменение имеет свою область действия. Смена ветки не подразумевает изменение правила консенсуса, более быстрое хеширование или изменение доказательства работы.
Изменение журнала майнинга было перенесено отдельно.
Один включенный коммит перемещает сообщение о весе CreateNewBlock за категорию отладки майнинга. ASIC.tools рассмотрел этот патч отдельно, поскольку частые запросы шаблонов блоков могут создавать повторяющиеся журналы. В контексте rc3 это просто одно из многих перенесенных операционных изменений. Администраторам пула, которым требуется эта строка, потребуется соответствующий параметр отладки в выпуске, который ее содержит; им не следует предполагать, что каждый установленный узел уже изменил поведение.
Официальные двоичные файлы rc3 еще не были в списке при проверке.
При редакционной проверке 2 октября официальный индекс загрузки Bitcoin Core все еще содержал подписанный каталог-кандидат 32.0rc2 от 22 сентября, тогда как каталог rc3 еще не был доступен. Подготовка системы контроля версий обычно предшествует воспроизводимым сборкам, подписям и публикации. Такое различие во времени предотвращает ошибочное представление объединенной версии как загружаемого подписанного программного обеспечения. Доступность может измениться позже, поэтому операторам следует проверять официальный индекс и подписи во время загрузки.
Пулы должны тестировать пути, которые они фактически используют.
Пулы майнинга, индивидуальные шлюзы и серверы шаблонов должны проверять кандидатов на соответствие getblocktemplate, оценке комиссии, сохранению мемпула, завершению работы и перезапуску, аутентификации RPC, мониторингу и оповещению. Тестовые узлы не должны делиться секретами производственного кошелька. Операторы должны сохранять сопоставимые журналы и показатели, проверять поведение кандидатов при реалистичной частоте запросов шаблонов и подтверждать, что нижестоящее программное обеспечение Stratum или программное обеспечение для распределения заданий обрабатывает ответы точно так, как ожидалось.
Проверка важнее ссылки для скачивания
При появлении двоичных файлов операторы должны использовать официальное место распространения Bitcoin Core, проверять SHA256SUMS и подписи, а также сравнивать политику подписывающих сторон, используемую их организацией. Кандидат на выпуск сначала должен быть установлен в изолированной тестовой среде. Сборка из исходного кода GitHub требует закрепления точного коммита и выполнения процесса воспроизводимой сборки. Ссылка, скопированная с форума или зеркала, не устанавливает соответствие пакета рассматриваемой ветке.
Что подтверждено, а что еще предстоит сделать
Подтвержденными фактами являются объединенная ветка rc3, три подготовительных коммита к ней и 29 коммитов между тегом rc2 и проверенной головой 32.x. Официальный финальный выпуск 32.0 все еще ожидался, и подписанные двоичные файлы rc3 еще не были видны в проверенное время. Следующее доказательство — это официальные артефакты-кандидаты, аттестации воспроизводимых сборок, отчеты тестировщиков и стабильный тег. Обновления производства должны соответствовать этим артефактам, а не только названию ветки.
Источник: Bitcoin Core ↗
Калькулятор майнинга ↗
