22 октября Bitcoin Core объединил изменение правил, которое открывает более быстрый путь для исправления уязвимостей: если считается, что злоумышленникам будет легко повторно обнаружить дефект, теперь его можно исправить сразу во всех поддерживаемых ветках выпусков, публикуя предупреждение по мере выхода каждого исправления. Это изменение принято на фоне данных сетевого снимка, сделанного Технологическим институтом Карлсруэ (KIT): 43,6% опрошенных общедоступных узлов Bitcoin Core работают на версиях, которые больше не получают исправлений.

Согласно новому правилу, разработчики могут классифицировать дефект на этапе первичной оценки, определяя, насколько легко его обнаружить повторно, в том числе с помощью больших языковых моделей. Разработчик Bitcoin Core Антуан Пуассон объявил об изменении в списке рассылки bitcoindev в объединённом запросе на изменение, обновляющем политику безопасности проекта. Он отметил, что прежний режим эмбарго мало чего даёт, но задерживает выпуск версии с исправлением. В качестве компромисса он указал, что у мер по снижению риска будет меньше времени, чтобы доказать свою эффективность в ветках разработки. По состоянию на 23 октября новая категория ещё не была публично применена ни к одной конкретной ошибке.

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

Как действовало прежнее правило

Практику проекта можно увидеть на примере раскрытия информации об уязвимости CVE-2024-52911. Уязвимость высокой степени серьёзности типа use-after-free при проверке блоков затрагивала версии новее 0.14.0 и старее 29.0. С её помощью специально сформированный недопустимый блок мог вызвать сбой узла. Об уязвимости сообщили в ноябре 2024 года, её исправили в версии 29.0 в апреле 2025 года, а раскрыли информацию 5 мая 2026 года — примерно через 388 дней после выпуска исправления. Эта практика продолжается: в примечаниях к выпуску 32.0 указано, что три ошибки средней или высокой степени серьёзности, исправленные в версии 30.0, останутся нераскрытыми до истечения двух недель после выхода новой версии.

Доля неподдерживаемых версий

Bitcoin Core поддерживает только три самые новые основные ветки релизов — сейчас это 29.x, 30.x и 31.x. Согласно снимку KIT от 18 октября, 3 671 из 8 422 пиров Bitcoin Core, указавших свою версию, работали на ветках, срок поддержки которых уже истёк; остальные использовали 31.x (3 243), 30.x (712) и 29.x (635). Подсчёт включает только общедоступные пиры IPv4 и IPv6, поэтому в него не входят узлы, работающие только через Tor, узлы, не принимающие входящие подключения, а также закрытая инфраструктура бирж, кастодианов и майнеров. Желающие узнать основы могут начать со статьи о том, что такое криптоузлы и как они работают.

Эта доля будет расти. Когда выйдет версия 32.0, ветка 29.x перестанет поддерживаться, а экстраполяция по данным снимка показывает, что 4 306 из 8 422 пиров, или 51,1%, будут работать на неподдерживаемых ветках, если состав выборки не изменится. По состоянию на 24 октября на странице проекта о жизненном цикле по-прежнему значилась дата выхода версии 32.0 — «будет объявлена позднее»; в каталоге загрузок были только релиз-кандидаты.

В Core 32.0 формат частично подписанной транзакции Bitcoin по умолчанию меняется с версии 0 на версию 2, что важно для мультисиг-систем, в которых сочетаются старые и новые узлы. Поскольку у Bitcoin нет центрального органа, который мог бы принудительно устанавливать обновления, безопасность сети зависит от того, решат ли операторы обновить ПО.