Проблема изменяемости транзакций

Проблема изменяемости транзакций стала известна сообществу биткойна (англ. bitcoin) в 2011 году.

В феврале 2014 года японская биржа биткойнов Mt. Gox объявила, что стала жертвой эксплойта в протоколе биткойна, получившего название «изменяемость транзакций». В то время Mt. Gox была крупнейшей в мире биткойн-биржей и обрабатывала около 70 % всех транзакций в сети биткойн. Хотя компания заявляла о потере биткойнов на сотни миллионов долларов из-за этой ошибки ^[5], независимые расследования показали, что с помощью данного эксплойта было украдено лишь около 386 биткойнов, а реальной причиной краха стали махинации и халатность руководства^[6][7]. После неудачных попыток привлечь инвесторов для покрытия убытков Mt. Gox приостановила вывод средств и закрыла свой веб-сайт^[8]. Вскоре компания подала заявление о банкротстве, а генеральный директор Марк Карпелес ушёл в отставку^[9].

Вскоре после заявления Mt. Gox администрация Silk Road 2.0 заявила о потере биткойнов на сумму 2,7 млн долларов из-за действий неизвестного хакера, который воспользовался уязвимостью изменяемости транзакций. Однако эксперты заподозрили, что уязвимость была использована как предлог для сокрытия хищения средств самими администраторами (экзит-скама)^[10].

В феврале 2014 года атаке также подверглась биржа Bitstamp, однако в этом случае уязвимость применялась не для кражи средств, а для организации DDoS-атаки, что вынудило площадку временно приостановить транзакции^[11].

Согласно исследованию 2014 года, опубликованному Кристианом Декером и Роджером Ваттенхофером, до инцидента с Mt. Gox значительных случаев эксплуатации изменяемости транзакций не фиксировалось^[12].

Изменяемость транзакций позволяет изменять уникальный идентификатор (ID) денежной транзакции до её подтверждения^[13]. В раннем коде Bitcoin уязвимость была обусловлена несколькими техническими причинами. Во-первых, подпись исключалась из подписываемого хеша: при её создании поле scriptSig временно заменялось на scriptPubKey из предыдущей транзакции, из-за чего подпись не защищала целостность самого поля scriptSig^[14][15]. Во-вторых, библиотека OpenSSL, использовавшаяся для проверки подписей, нестрого валидировала DER-кодирование и принимала нестандартные форматы (например, с добавлением лишних нулей)^[16][14]. В-третьих, математические свойства алгоритма ECDSA позволяли для любой валидной подписи с параметрами (r, s) вычислить альтернативную валидную подпись (r, -s (mod N))^[15]. В legacy-транзакциях возможны несколько форм манипуляций: ECDSA-комплемент (флип S-значения), нестандартное DER-кодирование (добавление лишних байтов) и избыточные операции scriptSig (добавление лишних данных или нестандартных опкодов без влияния на валидацию)^[17].

Злоумышленник может с помощью манипуляций с идентификатором транзакции (TXID) в сети биткойн ввести компьютерную систему в заблуждение, вынудив её ошибочно провести несколько транзакций^[18].

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

• Злоумышленник запрашивает легитимный вывод средств со своего баланса на собственный кошелёк^[19].
• Биржа формирует транзакцию, подписывает её, присваивает ей уникальный идентификатор (TXID) и транслирует в сеть^[19].^[20]
• Злоумышленник перехватывает эту транзакцию до её подтверждения майнерами и вносит незначительные технические изменения, которые не нарушают криптографическую подпись, но меняют итоговый хеш (TXID)^[21].^[20]
• Изменённая транзакция публикуется в сеть. Если майнеры первыми подтверждают её, перевод успешно завершается, а оригинальная транзакция отбрасывается^[19].^[21]
• Автоматизированная система биржи, отслеживающая статус вывода по первоначальному хешу, не находит его в блокчейне и ошибочно считает транзакцию неудачной^[19].^[20]
• В результате биржа автоматически возвращает средства на внутренний счёт злоумышленника (или он запрашивает их повторно), позволяя ему получить активы дважды^[19].^[20]

Подмена TXID также оказывает влияние на SPV-кошельки. Поскольку программное обеспечение таких кошельков отслеживает статус платежей по оригинальному идентификатору, при его изменении в сети возникает рассинхронизация интерфейса. Оригинальная транзакция отображается как неподтверждённая или отклонённая, что приводит к некорректному отображению балансов. Из-за этого пользователи могут ошибочно решить, что платёж не прошёл, и попытаться отправить средства повторно^[22].^[23]

Современные векторы включают атаки типа Fake Deposit (фиктивный депозит), использующие логические ошибки обработки хешей в пакетных (batch) транзакциях. Злоумышленники формируют пакетные транзакции, в которых крупный перевод намеренно завершается ошибкой, тогда как мелкие операции внутри пакета проходят успешно. Уязвимые системы мониторинга депозитов, опирающиеся только на общий статус транзакции, могут подтвердить зачисление, создавая видимость поступления средств без фактического увеличения баланса^[24].^[25]

Основным решением проблемы изменяемости транзакций стало внедрение протокола SegWit, который выносит данные подписей за пределы вычисления идентификатора транзакции (TXID). На 2026 год уровень принятия этой технологии составляет 85—90 %. Прямым развитием данной архитектуры выступают подписи Шнорра (в рамках обновления Taproot). Для повышения безопасности также применяется технология MAST, позволяющая скрывать неиспользуемые скрипты. Устранение уязвимости сделало возможным безопасное функционирование протоколов второго уровня, таких как Lightning Network. В качестве дополнительных мер защиты используются каноническая кодировка подписей (Low-S) и строгая валидация данных транзакций.