Я пытаюсь понять атаку податливых транзакций, поскольку мне кажется, что в первую очередь уязвим только довольно небрежный оператор, как описано ниже.
Главным образом для того, чтобы прояснить собственные мысли, позвольте мне описать нападение, как я его понимаю. Действующие лица: Алиса — злоумышленник, а Боб — «банкир» (оператор биржи, веб-кошелек; кто-то, кто хранит монеты на счету Алисы).
Алиса : Привет, Боб, у меня есть 1 BTC на моем счету, и я хочу снять его. Пожалуйста, отправьте его на адрес 1Alice1.
Боб : Хорошо, я сгенерировал транзакцию, ее хэш равен 123abc. Я только что разместил его в сети p2p. Он тратит выход 3 предыдущей транзакции 987def и отправляет 1 BTC 1Alice1. С вашего счета был списан 1 BTC, и ваш новый баланс равен 0.
Алиса : Спасибо, я вижу транзакцию. Я подожду подтверждения.
Теперь Алиса создает «мутантную» транзакцию с тем же эффектом, что и 123abc; он по-прежнему тратит вывод 3 987def и отправляет 1 BTC на 1Alice1, и подпись по-прежнему проверяется, но у мутанта другой хэш 456bca. Каким-то образом Алиса вводит в блокчейн 456bca вместо 123abc. Может быть, она просто лучше подключена к сети p2p, чем Боб, или, может быть, она подкупает Полли, оператора майнингового пула, чтобы она отдала приоритет 456bca. Поскольку 123abc конфликтует с 456bca, 123abc никогда не будет подтвержден.
Проходит некоторое время.
Алиса : Эй, Боб, помнишь, что я должна была получить 1 BTC? Транзакция так и не была подтверждена.
Боб : Позвольте мне проверить. Да, я вижу, в блокчейне нет такой транзакции, как 123abc. Что ж, я думаю, ты так и не получил свои монеты; прости за это. я пополню ваш счет; ваш новый баланс составляет 1 BTC.
Алиса : Спасибо. Теперь, когда у меня снова есть 1 BTC на моем счету, я хотел бы попытаться снова вывести его. Отправьте его 1Alice2.
Боб : Хорошо, я сгенерировал транзакцию, ее хеш равен 246fed. Я только что разместил его в сети p2p. Он использует вывод 7 предыдущей транзакции 369dbc. Ваш счет был дебетован, и баланс снова равен 0.
Транзакция 246fed подтверждается нормально.
Алиса : Попался, Боб! В конце концов, ваша первоначальная транзакция прошла, просто в форме мутанта как 456bca. Теперь у меня есть и она, и новая транзакция, и я только что украл у вас 1 BTC. Мва ха ха!
Боб : О, горе мне!
Однако похоже, что эта атака требует довольно небрежного учета со стороны Боба. Даже если Боб понятия не имеет, что существует такая вещь, как податливая транзакция, он знает, что сгенерировал 123abc и поместил его в сеть, и, насколько ему известно, он все еще циркулирует там. Поэтому я думаю, что прежде чем повторно кредитовать счет Алисы, здравый смысл подсказывает, что Боб должен убедиться, что 123abc не может быть подтвержден в какой-то момент в будущем, возможно, путем совершения новой транзакции (963dad), которая тратит те же входные данные (trans 987def output 3) на один из его собственные адреса (1Bob1) и ждет подтверждения от 963dad. Конечно, в текущем сценарии 963dad никогда не подтвердит (потому что 456bca заменяет его), и Боб в конце концов устанет ждать и продолжит расследование.
Или, альтернативно, когда Алиса просит вывести 1 BTC во второй раз, новая транзакция Боба (678bbb) к Алисе должна снова потратить тот же ввод (987def:3), гарантируя, что Алиса не сможет каким-то образом получить подтверждение 123abc позже. Это также мешает атаке, потому что 678bbb был признан недействительным 456bca.
Кроме того, поскольку мутантная транзакция Алисы 456bca действительно тратила входные данные Боба (987def:3), не должна ли клиентская программа Боба сообщить ему, что эти входные данные больше не доступны для него, и соответствующим образом скорректировать его баланс? Боб, по-видимому, считает, что 123abc потерпел неудачу, и поэтому он все еще контролирует этот ввод, и, следовательно, это должно нарушить баланс его бухгалтерских книг и предупредить его о том, что что-то не так.
Я так понимаю, что Бобы всего мира отреагировали на проблему, пожаловавшись на то, что «податливые транзакции» являются неясной ошибкой протокола, которую они никак не могли ожидать. Правда это или нет, но мне кажется, что для того, чтобы быть уязвимым, учетная практика Боба уже должна была быть небрежной, поэтому у него действительно нет защиты в любом случае.
Или, если Боб увидел красные флажки, но не смог понять ситуацию и все равно зачислил кредит на счет Алисы в интересах обслуживания клиентов, ему все равно трудно сочувствовать.
Является ли этот отчет по существу точным, или я упустил некоторые важные детали?
Спасибо, и извините за длину.
Хотя большая часть процесса, который вы описываете, точна, есть несколько деталей, в которых я считаю, что ваши предположения не соответствуют действительности, и, следовательно, могут привести к тому, что вы (немного) более критично относитесь к Бобу, чем действительно заслуживает:
Тот факт, что tx 123abc известен сети, не обязательно означает, что Боб, даже если он не знает о 456bca, должен опасаться, что 123abc может быть повторно отправлен. Каким-то образом его транзакции, в конце концов, продолжаются, что для большого объема транзакций, таких как централизованный кошелек, обычно означает, что неизрасходованная транзакция 987def, входящая в 123abc, тем временем уже была потрачена (и подтверждена). Боб может сказать это, даже не исследуя, какая транзакция заняла место 123abc, просто увидев подтверждение любых более поздних транзакций. Но, конечно, действия, которые можно было бы ожидать от Боба, расследуя, какие tx заменили 123abc (вместо того, чтобы естественно предположить, что только другие действительные tx могли быть сгенерированы его программным обеспечением горячего кошелька), должны были предотвратить мошенничество.
Что с другими причинами, потенциально препятствующими проведению транзакции — возможно, вы не включили достаточно комиссий или формировали транзакцию, которая в противном случае не понравилась пирам или майнерам для включения — это не является необоснованным чтобы горячий кошелек автоматически прибегал к повторной синхронизации с тем, что было включено в блокчейн, по сути, дважды тратя предыдущий tx 987def, чтобы можно было обработать, по крайней мере, других клиентов. Конечно, правильная обработка затем внутренне отметит это событие для ручной обработки неудачной транзакции, которая в этом эксплойте Алисы будет отсутствовать, а в идеальном процессе предупредит Боба о том, что что-то не так.
В распределенных системах не всегда существует общее глобальное состояние. То, что должно казаться естественным, если был, скажем, часовой перерыв в работе горячего кошелька для сравнения фактического баланса биткойнов и собственного учета, не так тривиально, как когда система постоянно находится в состоянии множества еще неподтвержденных транзакций. . Это не должно быть оправданием, потому что хорошо продуманный процесс аудита и сверки счетов должен справиться с этим, но, опять же, возможно, что ранее работавший менее сложный процесс не может справиться с проблемой большого количества неподтверждений. транзакции.
Я согласен, что, оглядываясь назад, Боб справился с ситуацией довольно плохо и не с тем усердием, на которое можно было бы надеяться от кого-то, кому доверили чужие биткойны. Но очень сложно разработать процессы, особенно в многолюдной круглосуточной работе, чтобы иметь дело с тем, что ошибочное представление заставляет вас считать совершенно невозможным. Боб, возможно, действительно работал с каким-то обходным процессом, чтобы справиться с его реализацией горячего кошелька, не обеспечивающей адекватного ведения журнала обычно не распространяющихся транзакций.
По сути, вы воспроизвели аргумент о том, что никому не нужно беспокоиться об этой проблеме, который, как мы теперь знаем, является ложным. Именно из-за этой самой веры у нас есть тот беспорядок, который мы имеем сейчас.
Одна важная деталь, которую вы упустили, заключается в том, что при расходовании результатов предыдущей транзакции вы должны указать ее идентификатор транзакции в своей новой транзакции. Таким образом, есть много других возможных сценариев отказа.
Например, предположим, что вы формируете только транзакции, которые тратят ваши собственные выходы, поэтому вы можете предположить, что ваши транзакции в конечном итоге обязательно завершатся успешно, и, таким образом, вы можете создавать цепочки транзакций, не дожидаясь подтверждений. До недавнего времени это считалось правильным способом генерировать большие объемы транзакций.
Но теперь мы понимаем, что вы не можете, потому что цепочка может полностью разорваться, если какая-либо транзакция в цепочке изменит свой идентификатор. Следующая транзакция, которая ссылается на любой из этих выходов, никогда не будет подтверждена, поскольку в одном из ее входов будет указан неправильный идентификатор транзакции. Более поздние транзакции, которые тратят на эту транзакцию, также потерпят неудачу, и у вас будет нечестивый беспорядок.
Первоначально я собирался сформулировать это как комментарий, но я достаточно уверен, чтобы рискнуть отрицательными голосами с ответом:
Что Боб должен был сделать, так это снова потратить исходные входные данные (возможно, просто повторно транслируя свой исходный txn). Если бы альтернативный txn уже был в блокчейне, новый txn был бы правильно отклонен как двойная трата, предупреждая Боба, что монеты фактически перешли из рук в руки.
С нетерпением жду, когда узнаю, почему мое простое объяснение неверно :)
Посмотрите это видео, предположительно демонстрирующее лайфхак на mtgox:
https://www.youtube.com/watch?v=WfKy3DEiOwY
Похоже, что gox автоматически рекредитовал его аккаунт после неудачной транзакции, что объясняет как несоответствие фиата (продайте взломанные монеты за фиат), так и несоответствие монет.
Теперь реальный вопрос:
Как эти идиоты из Gox не заметили?