Руководство по уязвимым сделкам: что озна

[coinspot]

Руководство по уязвимым сделкам: что означает «ошибка в Биткойн-коде»?

На прошлой неделе многие пользователи биткойнами впервые столкнулись с таким ранее неведомым термином, как «transaction malleability» (уязвимость или эластичность биткойн-транзакций). Именно эту пресловутую «уязвимость» биржа Mt.Gox назвала ключевой причиной приостановки операций по вводу/выводу средств на своей площадке. Кроме того, «уязвимость» фигурировала в качестве причины эксплойта, используемого при «массированной и согласованной атаке» против Bitcoin сети. Итак, что же это за явление,  как работает, и должно ли это нас беспокоить? Вот то, что нам удалось выяснить.

Источник

[icreator]

Но Ева делает вид, что Алиса никогда не пересылала ей монет. Она использует программный недостаток — «уязвимость транзакции» для того, чтобы дублировать оригинальную транзакцию Алисы, и слегка изменив подпись, сгенерировать совсем другой хеш. Затем она ретранслирует эту транзакцию уже с другим ID.

бред

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

[m0Ray]

Но Ева делает вид, что Алиса никогда не пересылала ей монет. Она использует программный недостаток — «уязвимость транзакции» для того, чтобы дублировать оригинальную транзакцию Алисы, и слегка изменив подпись, сгенерировать совсем другой хеш. Затем она ретранслирует эту транзакцию уже с другим ID.

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

Во-первых, подпись в ASN.1 может быть в разных кодировках. Кодировку можно поменять, подпись не изменится.
Во-вторых, как известно, транзакция в сети биткойн - это скрипт. А в скрипт можно добавить незначащие операции, не приводящие к изменению результата его работы.
В обоих случаях хэш всей транзакции меняется, а её смысл - нет.

[icreator]

я спросил кто может добавить? тот кто не имеет секретного ключа?

тоесть получил на входе транзакцию, поменял ее (имея только публичный ключ), создал новый хеш и ТХ_ИД и ретранслировал в сеть дальше - так чтоли?

[m0Ray]

Совершенно верно, да и публичный ключ не нужен. Фишка в том, что TXID и есть хэш всех данных транзакции.
Но проблема будет только у тех, кто однозначно привязал внутреннюю транзакцию к TXID и отслеживает успешность только по нему, что, видимо, и было у гокса. В референсном коде это давно пофиксили. Да и не было это особой проблемой, биткойны таким образом невозможно увести.

[apxu]

я спросил кто может добавить? тот кто не имеет секретного ключа?

тоесть получил на входе транзакцию, поменял ее (имея только публичный ключ), создал новый хеш и ТХ_ИД и ретранслировал в сеть дальше - так чтоли?

Да, именно так. "Гибкость" или "ковкость" транзакций позволяет поменять транзакцию так, что ее смысл останется тем же, а хеш изменится.
Для этого вообще никакой криптографии не надо знать - ни приватных, ни публичных ключей
Так как об этом написано уже в 100500 местах с примерами - я еще один раз объяснять не буду.

[dzyk]

Совершенно верно, да и публичный ключ не нужен. Фишка в том, что TXID и есть хэш всех данных транзакции.
Но проблема будет только у тех, кто однозначно привязал внутреннюю транзакцию к TXID и отслеживает успешность только по нему, что, видимо, и было у гокса. В референсном коде это давно пофиксили. Да и не было это особой проблемой, биткойны таким образом невозможно увести.

как долго мы вас ждали, спасибо за разьяснения... очень лаконично... и для всех

[icreator]

ну а как тогда у себя в базе запоминать транзакцию?

вот я получил с кошелька транзакцию что деньги пришли и запомнил ее в базе по ТХ_ИД + ВОУТ
и как меня могут обмануть?

[yurm]

вот я получил с кошелька транзакцию что деньги пришли и запомнил ее в базе по ТХ_ИД + ВОУТ
и как меня могут обмануть?

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

[m0Ray]

ну а как тогда у себя в базе запоминать транзакцию?

вот я получил с кошелька транзакцию что деньги пришли и запомнил ее в базе по ТХ_ИД + ВОУТ
и как меня могут обмануть?

Транзакция – это набор входов и выходов с суммами. TXID в ней вообще не нужен, он применяется до попадания транзакции в блоки для того, чтобы узел, которому от другого пришла транзакция, мог быстро понять, новая она или уже имеется во вре́менном хранилище транзакций. И быстро удалять их из временного хранилища, когда она попадает в блок. По сути это вре́менная штука.
Вас обмануть таким образом не могут. Могут обмануть отправителя, да и то только того, кто считает, что транзакция непременно попадёт в блоки в том виде, в котором он её сгенерировал (и не глядя повторит транзакцию, если не найдёт её в блоках, и ещё при этом случится так, что входы все не потрачены за предыдущий раз). А этого никто не гарантирует в сети биткойн. Гарантируется (и подписывается приватными ключами) только результат транзакции, а не её двоичное представление, скажем так.
Если надо ключик для локальной базы – соберите времянку из входов и выходов с суммами, а также временем её прихода – она с очень высокой вероятностью будет уникальной. Можно прохешировать её для унификации размера, но тут можно напороться на коллизию...

[icreator]

спасибо вас понял!

если в базе у меня есть сумма выплат и адрес куда ушла эта сумма + для быстрого поиска ТХ_ИД (но нету блока в который она включена), то:

?? если мне сказали что мой ТХ_ИД в блок не включен (но включен другой ТХ_ИД с этими же выплатами и входами), то меня могут развести, так как мой кошелек покажет что действительно такая транзакция с 0 подтверждениями... но на самом деле мои входы уже ушли на эти выходы, просто в блоке они имеют другой ТХ_ИД

блин как с этим мне бороться? запоминать дату создания транзакции и сумму выхода + адрес выхода? что-то много инфо получается надо хранить в базе данных...

или чистить ее каждый раз когда она включена в блок и получила скажем 3 подтверждения?

[m0Ray]

Да не надо вам ничего запоминать, клиент всё сделает за вас. Естественно, нормальный клиент, а не такой, который запоминает только TXID.
Блок, в который попадёт изменённая транзакция, дойдёт и до вашего клиента, и будет в нём видна.
Пользуйтесь оригинальным клиентом или другим, который знает о transaction malleability, и не будет проблем.
В который раз говорю: у гокса была своя реализация клиента, они про transaction malleability забыли или не стали париться по этому поводу. Вот и результат. Если они, конечно, правду говорят, что их поимели этим методом...

[icreator]

Да не надо вам ничего запоминать, клиент всё сделает за вас. Естественно, нормальный клиент, а не такой, который запоминает только TXID.
Блок, в который попадёт изменённая транзакция, дойдёт и до вашего клиента, и будет в нём видна.
Пользуйтесь оригинальным клиентом или другим, который знает о transaction malleability, и не будет проблем.
В который раз говорю: у гокса была своя реализация клиента, они про transaction malleability забыли или не стали париться по этому поводу. Вот и результат. Если они, конечно, правду говорят, что их поимели этим методом...

еще раз:
через АПИ даю команду перевести монеты и в ответ получаю ТХ_ИД которую запоминаю в своей БД
транзакцию кошелек шлет в сеть, там ее ТХ_ИД меняют и засовывают в блок
(а в моей базе данных лежит неизмененый ТХ_ИД)
даже пусть кошелек мой продвинутый и понял что в пришедшем блоке ТХ_ИД другой и для этой транзакции сам ее обновил...
но в моей базе данных то эта транзакция осталась у меня со старым ТХ_ИД...

тоесть мне тоже по пришествии блока смотреть свою транзакцию через АПИ кошелька и присваивать ей новый ТХ_ИД ??

тогда по старому ТХ_ИД я через АПИ смогу получить новый ТХ_ИД этой транзакции?? скорее всего нет - кошелек выдаст ошибку - мол такой транзакции нету...

[m0Ray]

Вот вы и пытаетесь наступить на те же грабли, т.е. использовать хэш двоичного представления транзакции в качестве её идентификатора...
Навскидку альтернативы:
• используйте лицевые счета (accounts) API bitcoind. Грубо говоря, эта штука позволяет поделить общий кошелёк на кармашки, и в каждом кармашке держать свою сумму. TXID здесь вообще не нужны, человек вводит-выводит свои средства и сразу видит сумму лицевого счёта, всем остальным занимаетcя bitcoind. Недостатки: использование bitcoind, который для очень больших нагрузок не очень хорош.
• генерируйте свой TXID на основt входов, выходов и сумм. Например, парсите транзакцию, у вас получается N входов с суммами и M выходов с суммами, подписи, комиссия и т.п. Сериализируете полученный объект в JSON-строчку (или в любой другой последовательный формат) и считаете хэш от неё. Недостатки: TXID, посчитанный вами, нигде нельзя будет проверить, это будет исключительно ваше, внутреннее представление транзакции.

[icreator]

Вот вы и пытаетесь наступить на те же грабли, т.е. использовать хэш двоичного представления транзакции в качестве её идентификатора...
Навскидку альтернативы:
• используйте лицевые счета (accounts) API bitcoind. Грубо говоря, эта штука позволяет поделить общий кошелёк на кармашки, и в каждом кармашке держать свою сумму. TXID здесь вообще не нужны, человек вводит-выводит свои средства и сразу видит сумму лицевого счёта, всем остальным занимаетcя bitcoind. Недостатки: использование bitcoind, который для очень больших нагрузок не очень хорош.
• генерируйте свой TXID на основt входов, выходов и сумм. Например, парсите транзакцию, у вас получается N входов с суммами и M выходов с суммами, подписи, комиссия и т.п. Сериализируете полученный объект в JSON-строчку (или в любой другой последовательный формат) и считаете хэш от неё. Недостатки: TXID, посчитанный вами, нигде нельзя будет проверить, это будет исключительно ваше, внутреннее представление транзакции.

1. способ не подходит так как если взять средства с кошелька то он со всех аккаунтов без разбора возьмет входы оставшиеся и балансы у всех уменьшатся. использовать lock или move вообще дурдом - если сделать рескан или еще чего балансы так же собьются. вообще использование аккаунтов в кошельке - это большая ошибка.
2. это вообще кошмар - каждую такую штуку потом вручную искать в каждом новом блоке?? ведь эту работу уже сделал "подвинутый" кошелек.. как у него через АПИ узнать/получить инфо об этом?

[m0Ray]

1. Ни фига, я так уже делал – баланс изменяется только у лицевого счёта (при использовании «sendfrom», разумеется). Можно переводить и между счетами. Главное – следить, чтоб баланс счёта не уходил в минус. Хотя это уже особенности сервиса – мабуть, вы хотите кредиты выдавать.
2. Да никакого кошмара же. Просто каждую транзакцию в пришедшем блоке пропустить через функцию вычисления «правильного» TXID (назовём это TXID2, чтоб н̶и̶к̶т̶о̶ ̶н̶е̶ ̶д̶о̶г̶а̶д̶а̶л̶с̶я̶ не путаться), и искать это в базе. А bitcoind вам не свяжет оригинальную транзакцию с модифицированной по TXID.
То есть нужна пара функций типа «tTransaction parse_transaction(tTXID txid)» и «tTXID2 generate_txid2(tTransaction transaction)». Первая возвращает разобранную транзакцию по TXID в виде объекта, вторая считает TXID2 по этому объекту. Пришёл блок – парсим все транзакции в нём, считаем TXID2 для каждой – и искать в базе. Что ужасного-то?

[yurm]

Просто каждую транзакцию в пришедшем блоке пропустить через функцию вычисления «правильного» TXID (назовём это TXID2, чтоб н̶и̶к̶т̶о̶ ̶н̶е̶ ̶д̶о̶г̶а̶д̶а̶л̶с̶я̶ не путаться), и искать это в базе.

В терминах blockchain.info это называется "normalized hash":

Normalized Hash Lookups
A Normalized Transaction Hash is a hash of the serialized transaction with it's input scripts blank. This hash cannot be altered through transaction malleability

    hashtontxid/TxHash - Convert a transaction hash to ntxid
    ntxidtohash/nTxID - Convert an ntxid to transaction hash

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

[m0Ray]

О, это уже стандартизировали? Прелестно, благодарю за информацию.

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

А я о том же. По расписанию или по событию ловить новые транзакции и отрабатывать.

[yurm]

О, это уже стандартизировали? Прелестно, благодарю за информацию.

Ну, blockchain.info — это вроде ещё не стандарт. За развитием стандарта наблюдать лучше здесь.

[m0Ray]

Ну да, «стандартизировали» – это я громко выразился. Но по крайней мере сделали общеизвестный алгоритм и API с возможностью проверки «правильного» хэша. От этого можно плясать.