Bitcoin Core опубликовал официальное раскрытие информации об уязвимости CVE-2025-62861 — дефекте высокой степени опасности в логике ретрансляции транзакций узлового ПО, из-за которого майнинговые операции могли продолжать хеширование по устаревшим шаблонам блоков без каких-либо видимых предупреждений. В рекомендациях заслуга обнаружения проблемы приписывается исследователю по безопасности Никласу Гёгге, а её причина связывается с правилом ретрансляции, сработавшим в неподходящий момент: во время реорганизации цепочки, когда оно должно было оставаться неактивным.

Затронуты версии от Bitcoin Core 28.0 до 28.2 и от 29.0 до 29.1. Исправление вышло в октябре 2025 года, однако полные технические детали удерживались до ноября 2026 года в соответствии с политикой скоординированного раскрытия информации проекта. В рекомендациях не упоминается ни один сбой и ни один пострадавший оператор; подверженность риску носит исторический характер. Майнинговое оборудование, подключённое к узлу в повреждённом состоянии, продолжало бы хешировать, но по последнему полученному шаблону, поэтому новые транзакции и их комиссии оставались бы невостребованными, пока кто-нибудь не заметил проблему.

Как реорганизация может осиротить транзакцию

Реорганизация происходит, когда узел отказывается от текущей вершины цепочки в пользу конкурирующей, более тяжёлой ветви. Транзакции в отключённых блоках остаются действительными, поэтому Bitcoin Core возвращает их в mempool — область хранения неподтверждённых транзакций. Поскольку эти транзакции уже были подтверждены в действительном блоке, узел добавляет их повторно с флагом bypass_limits, который отключает обычные антиспам-проверки и проверки топологии. Цель состоит в том, чтобы точно восстановить пул, а не пересматривать транзакции, уже прошедшие консенсус.

Одна из проверок, которые должны были быть отключены, касается транзакций версии три, или TRUC. Согласно BIP 431, TRUC-транзакция может иметь не более одной неподтверждённой родительской и одной неподтверждённой дочерней транзакции. Это политика ретрансляции, а не правило консенсуса: блок может легитимно содержать TRUC-родителя с несколькими дочерними транзакциями, хотя ни один узел не принял бы такую структуру в свой mempool из сети. Та же граница между политикой и консенсусом определила и границу самого дефекта: CVE-2025-62861 мог повредить mempool узла и остановить выдачу шаблонов, но не мог создать недействительный блок или изменить правила цепочки.

Начиная с версии 28.0, Bitcoin Core обеспечивает ограничение в одну дочернюю транзакцию с помощью механизма, называемого вытеснением сиблингов (sibling eviction). Когда новая транзакция даёт TRUC-родителю вторую неподтверждённую дочернюю транзакцию, узел рассматривает существующую дочернюю транзакцию как кандидата на замену и, если новая транзакция предлагает достаточную комиссию, вытесняет её по правилам замены по комиссии (replace-by-fee).

Дефект заключался в том, что вытеснение сиблингов выполнялось даже при установленном флаге bypass_limits. Реорганизация, восстанавливавшая TRUC-родителя с несколькими дочерними транзакциями — структуру, совершенно действительную внутри отключённого блока, — могла вызвать вытеснение одной восстановленной транзакции, оставив в пуле транзакции, тратившие её выходы. В mempool оказывались дочерние транзакции, чей родитель больше нигде не существовал: ни в цепочке, ни в пуле.

Исправление Грега Сандерса поставило TRUC-проверки в зависимость от bypass_limits, так что вытеснение больше не выполняется при восстановлении после реорганизации. Соответствующий pull-запрос, PR #33504, также добавил тестовый сценарий, отсутствовавший в исходном коде: транзакции, поступающие из отключённых блоков, а не от пиров.

Как выглядит остановленный шаблон со стороны майнинга

Узел передаёт работу майнинговому ПО через getblocktemplate, который собирает блок-кандидат, проверяет его собственной проверкой валидности узла и возвращает хеш предыдущего блока, выбранные транзакции и следующую высоту. При наличии в пуле «осиротевшей» транзакции собранный кандидат не проходил эту проверку, поэтому вызов не мог вернуть свежую работу.

Внешне узел выглядел исправным:

• Процесс запущен
• Соединения с пирами открыты
• Вершина цепочки продвигается
• Mempool принимает новые транзакции

Что было фактически сломано:

• Запрос шаблона возвращает ошибку
• Хешеры продолжают работать над устаревшей задачей
• На текущей вершине невозможно найти блок
• Состояние сохраняется до перезапуска узла

Всё, за чем следит типовая панель мониторинга, оставалось «зелёным». Сеть также не подавала никаких сигналов: вершина цепочки продолжала продвигаться — блоки всё ещё находились, только не этой операцией, — поэтому издержки ложились исключительно на остановившегося майнера: в виде хеширования, не способного найти блок на текущей вершине, и комиссий, которые он иначе получил бы. Единственное, что майнеру нужно от узла — актуальный шаблон, — оказалось единственным, что он перестал выдавать.

Перезапуск, патч и окончание поддержки

Перезапуск узла перезагружает mempool с диска в согласованном состоянии, что устраняет симптом. Но на причину это никак не влияет: следующая реорганизация с той же структурой транзакций могла снова остановить узел.

Корневой дефект был устранён в трёх релизах. Версия 30.0 вышла с исправлением 10 октября 2025 года, за ней последовали бэкпорты в 29.2 и 28.3. От закрытого отчёта до последнего из этих релизов прошло три недели:

С тех пор обе бэкпортированные ветки вышли из поддержки. Политика сопровождения Bitcoin Core охватывает три последние основные версии — сейчас это 30.x, 31.x и 32.x, — а 29.x достигла конца жизни 27 октября 2026 года. Оператор, ответивший на исходный сбой лишь перезапуском, теперь работает на неподдерживаемом коде, имея открытое описание того, какая именно структура транзакций её вызывает.

Почему рекомендации ждали 396 дней

От первого релиза с исправлением до подробных рекомендаций прошло 396 дней, а раскрытие состоялось ровно через две недели после окончания поддержки 29.x. Оба числа не случайны. Политика раскрытия информации Bitcoin Core удерживает детали уязвимостей средней и высокой опасности до истечения двух недель после прекращения поддержки последней затронутой версии, с предварительным анонсом за две недели до этого, приуроченным к выходу новой основной версии.

Эмбарго касалось объяснения, а не кода. Pull-запрос публичен с 29 сентября 2025 года, а в примечаниях к релизам 28.3 и 29.2 в то время упоминалось исправление mempool. В секрете в течение года оставалось лишь описание, связывающее патч с воспроизводимой остановкой майнинга.

Политика предусматривает и более быстрый путь. Дефекты, классифицированные как «легко обнаруживаемые» — что проект определяет как обнаружимые с минимальными усилиями, — получают немедленный точечный релиз и рекомендации без эмбарго. Этот случай прошёл по стандартному графику, поэтому сопровождающие не сочли его тривиальным для обнаружения. Он был опубликован в один день с двумя другими рекомендациями высокой и средней опасности, касавшимися остановки обработки блоков и ошибки прав доступа Tor; все три были исправлены в одном октябрьском релизном цикле 2025 года. Любая сборка, достаточно новая для содержания mempool-патча, следовательно, содержит и два других исправления.

Медленный путь воплощает собственное допущение: операторы обновляются в течение годового окна, так что к моменту публичного описания триггера никто из уязвимых его уже не слушает.

Что мониторить вместо времени работы

Для майнинговой операции полезная проверка — не то, жив ли узел, а каков возраст его последнего успешного шаблона. Процесс, который работает, подключён и синхронизирован, всё равно может перестать выдавать работу, и этот дефект был одним из способов, которым такое происходило незаметно. В ту же проверку следует включить версию сборки, потому что узел, актуальный по шаблонам сегодня, завтра может оказаться вне поддержки.

К резервным источникам шаблонов нужен тот же вопрос. Резервный узел на том же релизе с той же политикой mempool столкнулся бы с той же реорганизацией и той же остановкой; два запущенных процесса — не два независимых источника работы. Майнинг сохранила бы только работа на узле с другой, пропатченной сборкой, и только оператор, проверивший это при симулированной реорганизации, знал бы об этом заранее.