Ошибка эмиссии, которую сначала назвали сбоем

Что именно нарушалось

Каждый вход транзакции указывает на ранее созданный непотраченный выход. Один выход можно потратить только один раз. Проверка кажется очевидной, но она проходит через несколько уровней: предварительную проверку транзакции, проверку блока и обновление набора UTXO.

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

Как безобидная оптимизация открыла путь

В Bitcoin Core 0.14 удалили повторную дорогую проверку одинаковых входов на раннем этапе обработки блока. Предполагалось, что более поздняя логика UTXO всё равно обнаружит нарушение. В одной ветви кода это действительно приводило к assertion и остановке.

Затем переработка учёта UTXO в версии 0.15 немного изменила условие assertion. Для выхода, созданного в более раннем блоке, повторная трата могла пройти без падения. Оптимизация не создавала новые правила намеренно; она разорвала прежнее дублирование защиты, а следующий рефакторинг изменил оставшийся предохранитель.

Почему использовать ошибку мог не любой узел

Недействительная транзакция должна была находиться внутри блока. Обычный участник не мог просто разослать её через mempool: стандартные проверки отвергли бы конфликт. Для атаки требовался майнер, готовый построить специальный блок.

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

Хронология первых часов

Анонимный исследователь сообщил о crash-баге 17 сентября в 14:57 UTC нескольким разработчикам разных Bitcoin-проектов. В 17:47 команда определила, что корень проблемы допускает инфляцию. Началась связь с майнинговыми пулами и крупной инфраструктурой.

В 21:57 был опубликован патч с тестом, демонстрировавшим отказ в обслуживании. Версию 0.16.3 пометили ночью, а готовые файлы и объявление об обновлении появились 18 сентября.

Почему публично говорили только о падении

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

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

Что произошло на практике

Официальное раскрытие сообщало, что разработчикам не известно об эксплуатации ошибки в основной сети. Позднее уязвимость проверили в testnet: старые узлы либо падали, либо принимали недействительную цепочку и затем не могли корректно вернуться без вмешательства.

Testnet-эпизод показал, что риск не был теоретической фантазией. Одновременно отсутствие известной атаки в mainnet показывает ценность быстрого сообщения, координации обновления и сдержанного раскрытия деталей.

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

Первый вывод — консенсусный код опасно оптимизировать, даже если удаляемая проверка выглядит повторной. Защитные слои могут зависеть друг от друга неочевидным образом.

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

Третий — децентрализация не отменяет человеческую координацию во время аварии. Разработчики не могли заставить узлы обновиться, но могли выпустить исправление, объяснить срочность и связаться с участниками, от скорости которых зависел риск.

Как раскрывают уязвимости сегодня

Bitcoin Core публикует политику с уровнями критичности. Низкие ошибки раскрываются вскоре после исправления; средние и высокие — после завершения поддержки затронутой ветви. Критические случаи могут требовать отдельной процедуры.

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