Cointime

Download App
iOS & Android

Дублирующие транзакции в биткоинах: забавный баг с минимальным риском

Cointime Official

Автор: BitMEX Research

В блокчейне биткойна есть два идентичных набора транзакций, один набор транзакций «накладывается» на другой набор транзакций, и оба произошли в середине ноября 2010 года. Дублирующиеся транзакции могут привести к путанице, и разработчики биткойнов на протяжении многих лет боролись с этим различными способами. Эта проблема все еще не решена на 100%, и следующая потенциальная дублирующая транзакция может произойти в 2046 году. Хотя риски, связанные с дублирующими транзакциями, сейчас минимальны, это интересная особенность, о которой стоит задуматься.

Обзор

Обычная транзакция Bitcoin использует как минимум один выход из предыдущей транзакции, ссылаясь на идентификатор транзакции (TXID) предыдущей транзакции. Эти неизрасходованные выходы можно потратить только один раз. Если бы их можно было потратить дважды, вы бы потратили свой биткоин дважды, сделав его бесполезным. Однако на самом деле в биткоине существует ровно два идентичных набора транзакций. Это возможно, поскольку транзакция coinbase не имеет никаких входов транзакции, а вместо этого имеет вновь сгенерированные монеты. Таким образом, две разные транзакции Coinbase могут отправить одну и ту же сумму на один и тот же адрес и быть построены совершенно одинаково, что делает их идентичными. Поскольку эти транзакции идентичны, TXID также совпадают, поскольку TXID представляет собой хэш-дайджест данных транзакции. Единственный другой способ копирования TXID — это коллизия хэшей, что считается маловероятным и недостижимым для криптографически безопасных хэш-функций. Коллизии хэшей, подобные SHA256, никогда не случались ни в Биткоине, ни где-либо еще.

Оба набора дублирующих транзакций произошли в одно и то же время: между 08:37 UTC 14 ноября 2010 г. и 00:38 UTC 15 ноября 2010 г., то есть с интервалом около 16 часов. Первый набор дублирующихся транзакций находится между вторым набором. Мы классифицируем d5d2….8599 как первую дублирующую транзакцию, поскольку она стала первой дубликатной, хотя, как ни странно, она впервые появилась в блокчейне после другой дублирующей транзакции, e3bf….b468.

Повторите детали транзакции

На изображениях ниже вы можете видеть два снимка экрана из обозревателя блоков mempool.space, на которых показана первая дублирующая транзакция, повторяющаяся в двух разных блоках.

Интересно, что при вводе соответствующих URL-адресов в веб-браузер обозреватель блоков mempool.space по умолчанию отображает более ранний блок в случае d5d2….8599 и более поздний блок в случае e3bf….b468. Blockstream.info и Btcscan.org ведут себя так же, как mempool.space. С другой стороны, согласно нашему базовому тестированию, Blockchain.com и Blockchair.com ведут себя по-разному и всегда отображают последнюю версию дублирующей транзакции при вводе URL-адреса в браузере.

Из четырех рассматриваемых блоков только один (блок 91 812) содержал какие-либо дополнительные транзакции. Эта транзакция объединяет выходы 1 BTC и 19 BTC в один выход 20 BTC.

Можно ли потратить эти результаты?

Это создало проблему ссылок для последующих транзакций, поскольку существовало два набора одинаковых TXID. Каждая повторяющаяся транзакция стоит 50 BTC. Таким образом, эти повторяющиеся транзакции в общей сложности включают 4 x 50 BTC = 200 BTC или, в зависимости от того, как вы это понимаете, 2 x 50 BTC = 100 BTC. В некотором смысле, есть 100 BTC, которых на самом деле не существует.

На сегодняшний день все 200 BTC остаются неизрасходованными. Насколько нам известно (и мы можем ошибаться), если у кого-то есть закрытые ключи, связанные с этими выходами, он может потратить эти биткоины. Однако после расходования UTXO будет удален из базы данных, а дубликаты 50 BTC станут неиспользованными и будут утеряны, поэтому восстановить можно будет только 100 BTC. Что касается того, из какого блока поступят эти монеты, если они будут потрачены, более раннего или более позднего, то это может быть неопределенно или невозможно определить.

Этот человек мог потратить все биткоины до создания дублирующей транзакции, которая затем создала бы дублирующие выходы, создав новые записи в базе данных неизрасходованных выходов. Это будет означать не только дублирование транзакций, но и дублирование транзакций, которые могут иметь дублирующиеся потраченные результаты. Если это произойдет, то при расходовании этих выходов, скорее всего, будет создано больше дублирующих транзакций, образуя своего рода дублирующую цепочку. Необходимо быть внимательным с порядком событий и всегда тратить деньги перед созданием дубликата, иначе биткоины могут быть потеряны навсегда. Эти новые дублирующие транзакции не будут транзакциями Coinbase, а будут «обычными» транзакциями. К счастью, этого не произошло.

Проблема дублирующих транзакций

Дублирующие транзакции — это, очевидно, плохо. Они создают путаницу для кошельков и обозревателей блоков, а также скрывают происхождение биткоинов. Это также открывает множество возможностей для атак и уязвимостей. Например, вы можете заплатить кому-то дважды, совершив две дублирующие транзакции. Затем, когда стороны сделки решат попытаться получить доступ к средствам, они могут обнаружить, что для возврата доступна только половина средств. Это может быть, например, атака на торговую платформу с целью ее банкротства, при этом злоумышленник ничего не теряет, поскольку он может вывести свои средства сразу после внесения.

Запретить транзакции с дублирующимися TXID

Чтобы решить проблему дублирующихся транзакций, в феврале 2012 года разработчик Bitcoin Питер Вюйле предложил решение на основе софтфорка BIP30, которое запрещает использование дублирующихся TXID для транзакций, если предыдущий TXID не был потрачен. Этот софтфорк применяется ко всем блокам после 15 марта 2012 года.

В сентябре 2012 года разработчик Bitcoin Грег Максвелл изменил это правило таким образом, чтобы проверка BIP30 применялась ко всем блокам, а не только к тем, которые были созданы после 15 марта 2012 года. Исключением являются две дублирующие транзакции, упомянутые ранее в этой статье. Это исправляет некоторые ошибки DOS. Технически это еще один софт-форк, хотя изменение правил применяется только к блокам старше 6 месяцев, поэтому оно не несет никаких рисков, связанных с обычными изменениями правил протокола.

Проверка BIP30 требует больших вычислительных затрат. Узел должен проверить все выходные данные транзакций в новом блоке и проверить, существуют ли уже эти выходные конечные точки в UTXO. Вероятно, именно поэтому Вюйле проверяет только неиспользуемые выходы; проверка всех выходных данных потребовала бы больших вычислительных затрат и не позволила бы выполнить обрезку.

БИП34

В июле 2012 года разработчик Bitcoin Гэвин Андресен предложил решение софт-форка BIP34, которое было активировано в марте 2013 года. Это изменение протокола требует, чтобы транзакции Coinbase включали высоту блока, что также позволяет управлять версиями блоков. Высота блока добавляется как первый элемент скрипта транзакции Coinbase Sig. Первый байт в coinbase scriptSig — это количество байтов, используемых номером высоты блока, а следующие байты — это сам номер высоты блока. В течение первых 160 лет (223 / (144 блока в день * 365 дней в году)) первый байт должен быть 0x03. Вот почему сегодняшний coinbase ScriptSig (HEX) всегда начинается с 03. Этот софтфорк, похоже, полностью решил проблему дублирования транзакций, и теперь все транзакции должны быть уникальными.

Поскольку BIP34 уже был принят, в ноябре 2015 года разработчик Bitcoin Алекс Моркос добавил запрос на извлечение в репозиторий программного обеспечения Bitcoin Core, что означало, что узлы перестанут выполнять проверки BIP30. В конце концов, теперь, когда BIP34 решает эту проблему, эта дорогостоящая проверка больше не нужна. Хотя в то время об этом не было известно, технически это был хард-форк для некоторых очень редких будущих блоков. На данный момент потенциальный хардфорк, похоже, не имеет значения, поскольку почти никто не использует программное обеспечение узлов, выпущенное до ноября 2015 года. На forkmonitor.info мы используем Bitcoin Core 0.10.3, выпущенный в октябре 2015 года. Так что это правило действует до хардфорка, и клиенты по-прежнему выполняют дорогостоящую проверку BIP30.

Блок,983,702 Вопросы

Оказывается, до активации BIP34 в блоках были транзакции coinbase, где первый байт использованного scriptSigs совпадал с допустимой высотой будущего блока. Таким образом, хотя BIP34 и решает эту проблему почти во всех случаях, это не решение на 100%. В 2018 году разработчик биткоина Джон Ньюбери распечатал полный список потенциальных дубликатов, как показано в таблице ниже.

* Примечание: эти блоки сгенерировали транзакции Coinbase в 2012 и 2017 годах и не являются дубликатами. 209 921 блок (всего 79 блоков до первого халвинга) не могут быть дубликатом, поскольку в это время был реализован BIP30.

Источник: https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd

Количество потенциально дублирующих транзакций Coinbase по годам

Источник: https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd

Таким образом, следующим блоком, в котором могут появиться дублирующие транзакции, будет блок 1 983 702, который будет сгенерирован примерно в январе 2046 года. Транзакция Coinbase в блоке 164 384 в январе 2012 года отправила 170 BTC на семь разных выходных адресов. Таким образом, если бы майнеры в 2046 году захотели осуществить эту атаку, им бы не только посчастливилось найти этот блок, но и пришлось бы потратить менее 170 BTC на комиссии, что в сумме составило бы чуть более 170 BTC, включая альтернативную стоимость субсидии на блок в размере 0,09765625 BTC.

При текущей цене биткоина в 88 500 долларов это обойдется более чем в 15 миллионов долларов. Что касается того, кому принадлежат семь адресов транзакций нумизматической библиотеки в 2012 году, то это до сих пор неизвестно, а ключи, скорее всего, были утеряны. В настоящее время были использованы все семь выходных адресов этой транзакции Coinbase, три из которых использовались в одной и той же транзакции. Мы полагаем, что эти средства могут быть связаны с финансовой пирамидой Pirate40, но это всего лишь наши предположения. В результате атака оказывается не только дорогостоящей, но и практически бесполезной для злоумышленника. Удаление узла ноября 2015 года из сети 31 год назад в результате хардфорка потребовало бы значительных затрат.

Следующий уязвимый блок, который можно было скопировать, — это блок 169985 в марте 2012 года. На Coinbase он стоил всего чуть более 50 BTC, что намного меньше 170 BTC. Конечно, в то время субсидией была сумма в 50 BTC, а когда эта транзакция Coinbase станет легко повторяемой в 2078 году, субсидия будет намного ниже. Таким образом, чтобы воспользоваться этим, майнерам придется сжечь около 50 BTC в виде комиссий, которые они не смогут вернуть, поскольку их придется отправить на старый вывод 2012 года. Никто не знает, какой будет цена биткоина в 2078 году, но стоимость такой атаки также, вероятно, будет непомерно высокой. Таким образом, эта проблема, возможно, не представляет серьезного риска для Bitcoin, но все же вызывает беспокойство.

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

в заключение

Учитывая сложность и стоимость копирования сделок, а также редкость возможности его использования, эта уязвимость копирования сделок, по-видимому, не является серьезной проблемой безопасности для Bitcoin. Тем не менее, об этом интересно поразмыслить, учитывая временные рамки и новизну повторяющихся транзакций. Тем не менее, разработчики потратили много времени на решение этой проблемы на протяжении многих лет, и дата 2046 года может стать для некоторых разработчиков крайним сроком ее устранения. Есть много способов исправить эту ошибку, и может потребоваться софт-форк. Одним из возможных решений является обеспечение соблюдения обязательств SegWit.

Комментарий

Все комментарии

Рекомендуем к прочтению