Bitcoin Core добавил bestblockhash в getmininginfo против гонок шаблонов
Публикация источника: 2026-09-14 · Редакционный анализ опубликован: 2026-09-19
Слитый патч даёт майнинговому ПО хеш вершины и данные следующей цели в одном согласованном RPC-снимке.

Анализ и практические выводы
В этом разделе — наш анализ и условные расчёты, отдельно от сообщения источника.
Что именно слили
Pull request Bitcoin Core #36081 был влит в master 14 сентября 2026 года. Он добавляет bestblockhash в ответ RPC getmininginfo. Майнинговое ПО уже читало следующую высоту, nBits и target из объекта next; теперь оно сможет определить точную вершину цепи, из которой получены значения. Это слитый код разработки, а не доказ наличия поля на каждом развёрнутом узле.

Гонка между двумя RPC
Раньше ПО, которому нужны хеш вершины и цель следующего блока, вызывало getmininginfo, затем getbestblockhash или getblockchaininfo. Между запросами tip мог измениться, и получалась пара хеша одной вершины с target другой. Автор выделил реорганизации одинаковой высоты у границы retarget, где конкурирующие tips могут означать разные next nBits. Редкий сценарий не безвреден, если данные идут в шаблон блока.
Почему один снимок безопаснее
Возврат связанных полей под одной внутренней блокировкой состояния даёт согласованный снимок. Хеш становится маркером версии: ПО связывает next-target с конкретной вершиной и обнаруживает устаревание после новой. Это не отменяет реорганизации и не заменяет getblocktemplate. Патч убирает одну предотвратимую несогласованность на границе RPC и упрощает проверку состояния пулом.
Развёртывание не мгновенно
Слияние в master попадает в ветку разработки. Оператору нужно проверить будущий релиз и backport в своём дистрибутиве. Клиент должен определять наличие bestblockhash, а не предполагать его, особенно в смешанном парке узлов. Безопасный rollout сохраняет старый fallback из двух вызовов с проверкой согласованности, тестирует парсер на записанных ответах и обновляет мониторинг до production.
Тесты для разработчиков пула
Протестируйте обычную смену tip, реорганизацию той же высоты, границу retarget и перезапуск узла. Кеш шаблонов должен сбрасываться при изменении bestblockhash, даже без смены высоты. Отсутствующий или неверный хеш обрабатывайте без падения, записывая версию и доступность поля. При нескольких узлах failover не должен смешивать снимки. Метрики должны считать stale responses и fallback до роста rejected work.
Практическое значение
Патч мал, но следует важному правилу: данные, интерпретируемые вместе, должны иметь общий контекст версии. Пул не получит хешрейт, но уменьшит узкий класс гонок состояния шаблона и улучшит диагностику. Следите за релизом, поэтапно добавляйте поддержку и сохраняйте прежние проверки. GitHub pull request — авторитетная запись статуса, review и истории commit.
Источник: Bitcoin Core ↗
Калькулятор майнинга ↗

