Bitcoin Core добавил категорию mining для журнала шаблонов блоков
Публикация источника: 2026-09-29 · Редакционный анализ опубликован: 2026-10-01
Изменение переносит повторяющуюся строку CreateNewBlock о весе блока под параметр -debug=mining. Код уже в master и ветке 32.x, но ещё не в финальном релизе.
Анализ и практические выводы
В этом разделе — наш анализ и условные расчёты, отдельно от сообщения источника.
Часто повторяющаяся строка журнала больше не является безусловной.
29 сентября 2026 года сопровождающие Bitcoin Core объединили запрос на извлечение 36336. Он перемещает сообщение о весе блока CreateNewBlock в новую категорию отладки майнинга. Ранее эта строка записывалась безоговорочно всякий раз, когда узел создавал шаблон блока и мог заполнять файл debug.log в системах, которые часто запрашивают шаблоны. После изменения операторы, которым нужно это сообщение, включают его с помощью -debug=mining, а установки, которым не нужны подробности, могут избежать повторного ввода.
Операторы пула и шаблонов должны проверить настройки ведения журналов.
В примечаниях к выпуску особенно рекомендуется, чтобы пользователи getblocktemplate и пользователи Mining IPC включали категорию майнинга, если они полагаются на эти сообщения. Пулы, шлюзы для индивидуального майнинга и системы тестирования часто создают шаблоны блоков гораздо чаще, чем обычный узел кошелька. Конфигурация, которая ранее собирала строку автоматически, может потерять ее после обновления до версии, содержащей патч. Перед развертыванием операторам следует проверять оповещения на основе журналов, анализаторы и процедуры устранения неполадок.
В сообщении сообщается вес шаблона блока.
CreateNewBlock создает блоки-кандидаты из текущей вершины цепочки и мемпула с учетом ограничений политики и консенсуса. Затронутое сообщение сообщает вес блока-кандидата. Это может помочь разработчикам проверить поведение шаблона, но не является доказательством того, что блок был добыт, отправлен или принят сетью. Перемещение линии в категорию меняет только наблюдаемость; он не меняет выбор транзакций, доказательство работы, действительность блока или вознаграждение за майнинг.
Новая категория соответствует элементам управления отладкой Bitcoin Core.
Bitcoin Core поддерживает ведение журнала отладки по конкретным категориям, поэтому операторы могут выбирать подсистемы, необходимые для диагностики. С этим патчем -debug=mining включает сообщение шаблона блока, в то время как нормальная конфигурация может оставаться тише. Точный синтаксис командной строки или bitcoin.conf должен быть проверен на этапе подготовки, особенно если менеджеры сервисов или образы контейнеров автоматически генерируют аргументы. Включение большего количества журналов также требует соответствующих ограничений ротации и хранения дисков в долгосрочной инфраструктуре пула.
Патч объединен, но не является новой финальной версией.
Изменение было добавлено в основную ветку после проверки и 27 автоматических проверок. Сопровождающий также сообщил, что функциональное изменение было перенесено в ветку 32.x 30 сентября. Объединенный или перенесенный патч — это не то же самое, что окончательный пакет выпуска Bitcoin Core. Операторам следует дождаться официального релиза с тегами, если у них еще нет контролируемого процесса создания и проверки ветвей разработки.
Существующим парсерам может потребоваться явная проверка.
В комментарии к обзору отмечено, что при поиске анализаторов точной весовой линии CreateNewBlock не было найдено никаких заслуживающих внимания внешних проектов, но отсутствие в общедоступном поиске не распространяется на инструменты частного пула. Перед обновлением командам следует найти свои собственные правила мониторинга, регистрировать отправителей и информационные панели на предмет этой фразы. Безопасный тест генерирует повторяющиеся запросы getblocktemplate с параметром -debug=mining и без него, подтверждает ожидаемое поведение сообщения и проверяет, остаются ли видимыми несвязанные журналы ошибок.
Более тихие журналы уменьшают объем хранения и шум сигнала.
Для высокочастотной службы шаблонов безусловная строка может привести к ненужной записи на диск и затруднить поиск важных предупреждений. Разделение по категориям позволяет оператору выбирать между подробной диагностикой горных работ и общим журналом меньшего размера. Преимущество заключается в эксплуатации, а не в увеличении хешрейта или эффективности: оно не делает ASIC быстрее и не снижает его электрическую нагрузку. Однако это может улучшить сохранение журналов и упростить проверку инцидентов на узлах, поддерживающих пул майнинга.
Не отключайте диагностические данные без замены
Если пул использует тенденции веса шаблонов для обнаружения необычных условий мемпула или регрессий сборки блоков, ему следует сохранить категорию интеллектуального анализа или собрать эквивалентные метрики из тестируемого интерфейса. Журналы также должны ротироваться, иметь временные метки и отправляться в хранилище, размер которого соответствует ожидаемой частоте запросов. Правильная настройка зависит от цели системы: легкий узел может предпочитать минимальный объем вывода, тогда как производственный пул может ценить полную диагностику шаблона во время обновлений.
Следующая контрольная точка — официальный релиз.
Подтвержденные факты ограничены: запрос на включение был объединен, сообщение перемещено за категорию майнинга, примечания к выпуску предупреждают пользователей getblocktemplate и Mining IPC, а код был перенесен в 32.x. В этом запросе на включение окончательный номер версии и дата выпуска не устанавливаются. Операторам следует прочитать официальные примечания к выпуску и подписанные двоичные файлы при появлении следующего выпуска, а затем проверить точную конфигурацию журналирования перед развертыванием рабочей среды.
Источник: Bitcoin Core ↗
Калькулятор майнинга ↗
