Все понятно! Без паники!
Атака
http://www.coindesk.com/massive-concerted-attack-launched-bitcoin-exchanges/
Topic: Гокс пишет про баг в bitcoin (Read 4239 times)
Все это относительно понятно. Но как расценивать вчерашнее заявленте штампа?
Им софт тоже школьник писал? У гокса похоже начиналось...
Что то очень быстро все происходить стало...
Или это действительно атака-провокация-нападение?
Quote
Bitstamp’s exchange software is extremely cautious concerning Bitcoin transactions. Currently it has suspended processing Bitcoin withdrawals due to inconsistent results reported by our bitcoind wallet, caused by a denial-of-service attack using transaction malleability to temporarily disrupt balance checking. As such, Bitcoin withdrawal and deposit processing will be suspended temporarily until a software fix is issued.
No funds have been lost and no funds are at risk.
This is a denial-of-service attack made possible by some misunderstandings in Bitcoin wallet implementations. These misunderstandings have simple solutions that are being implemented as we speak, and we're confident everything will be back to normal shortly.
Withdrawals which failed on the 10th and 11th of February will be canceled and the amounts added back to the customer account balances.
We will communicate any further developments regarding this issue.
Типа у нас кошель ерунду показывает, мы его прикроем пока не поймем...No funds have been lost and no funds are at risk.
This is a denial-of-service attack made possible by some misunderstandings in Bitcoin wallet implementations. These misunderstandings have simple solutions that are being implemented as we speak, and we're confident everything will be back to normal shortly.
Withdrawals which failed on the 10th and 11th of February will be canceled and the amounts added back to the customer account balances.
We will communicate any further developments regarding this issue.
Им софт тоже школьник писал? У гокса похоже начиналось...
Что то очень быстро все происходить стало...
Или это действительно атака-провокация-нападение?
Гокс по ходу крысы.
Всё это высасано из пальца, чтобы биточки увести.
Всё это высасано из пальца, чтобы биточки увести.
сами бабла наколотили, а топом типа сорри у нас тут глюконуло
Прошу прощения, эта ссылка не очень проясняет ситуацию, лучше эта:
https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx
(особое внимание обратите на пп. 5 и 6).
https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx
(особое внимание обратите на пп. 5 и 6).
Достаточно ли будет добавить к выводу информации о транзакции добавить поле inputhash, равное хешу от списка отсортированных txid входов? Соответственно утилиты проверки 'ушла ли транзакция или нет' должны ожидать, что хотя бы одна транзакция с искомым inputhash подтвердилась, чтобы исходящую транзакцию считать завершенной.
По уму в качестве id стоило бы использовать хэш ровно тех полей, которые реально подписываются. Для стандартного SIGHASH_ALL это txid/vout и nsequence каждого входа (без scriptSig, как сейчас) и value + scriptPubKey для каждого выхода. Проблема в том, что в пределах одной транзакции могут быть входы с разными SIGHASH_ (например, один с SIGHASH_ALL, а другой с SIGHASH_ALL|SIGHASH_ANYONECANPAY) и, соответственно, с разными покрытиями подписей. А использовать для одной транзакции несколько разных id как-то некрасиво.Впрочем, для личного отслеживания (без включения в bitcoin-протокол) использовать такие id, думаю, можно.
И после этого ecdsa-подписи скриптов снановятся инвалидными (т.е. подпись не соответствует скрипту)... Значит проверку на подпись они не пройдут. Сказано проверять подписи скриптов. Так в чём проблема-то ?
Не становятся. По очевидным причинам ecdsa-подпись не покрывает поле scriptSig.https://en.bitcoin.it/wiki/OP_CHECKSIG
https://bitcointalksearch.org/topic/m.4912522
Нужно объяснять, почему эта причина очевидна?
Меняются именно scriptSig, например, добавлением OP_NOP в них, при этом сами ecdsa-подписи не меняются. Да,
И после этого ecdsa-подписи скриптов снановятся инвалидными (т.е. подпись не соответствует скрипту)... Значит проверку на подпись они не пройдут. Сказано проверять подписи скриптов. Так в чём проблема-то ? @awoland ты совсем не понимаешь проблемы?
Ты создаешь исходящую транзакцию, по всем правилам валидную, с комиссией и т.п., но тут же после у тебя появляется в кошельке еще одна транзакция, которую ты не делал, подтверждается сетью и списывает точно такую же сумму на те же адреса что ты указал, а твоя транзакция так и не добавляется в блокчейн.
Как ты пометишь у себя что созданный тобой перевод подтвердился сетью и деньги ушли? Я говорю про автоматизированные средства выплат с тысячами транзакций в час, а не ручную обработку трех в месяц!
Входы-выходы и суммы не меняются, наверняка что-то еще уникальное.. делай проверку по этому.Ты создаешь исходящую транзакцию, по всем правилам валидную, с комиссией и т.п., но тут же после у тебя появляется в кошельке еще одна транзакция, которую ты не делал, подтверждается сетью и списывает точно такую же сумму на те же адреса что ты указал, а твоя транзакция так и не добавляется в блокчейн.
Как ты пометишь у себя что созданный тобой перевод подтвердился сетью и деньги ушли? Я говорю про автоматизированные средства выплат с тысячами транзакций в час, а не ручную обработку трех в месяц!
по уму обсудить бы, какую форму защиты от подобного, можно было предложить для внедрения в bitcoind.
Достаточно ли будет добавить к выводу информации о транзакции добавить поле inputhash, равное хешу от списка отсортированных txid входов? Соответственно утилиты проверки 'ушла ли транзакция или нет' должны ожидать, что хотя бы одна транзакция с искомым inputhash подтвердилась, чтобы исходящую транзакцию считать завершенной.
Выше вам уже ответили: нужно проверять входы-выходы транзакций (подписи скриптов). Эти вещи без приватных ключей изменить невозможно.
Вы эту статью внимательно читали? А эту? Меняются именно scriptSig, например, добавлением OP_NOP в них, при этом сами ecdsa-подписи не меняются. Да,Currently transactions with anything other than data push operations in their scriptSig are considered non-standard and are not relayed
но это не мешает злоумышленникам поднять свой пул и принимать такие транзакции.Прикажете извлекать сами ecdsa-подписи из scriptSig? А если scriptSig сильно изменил свою форму путём добавления всяких бессмысленных данных с OP_DROP'ами? Проверку подписей стоит делегировать самому клиенту, а сигналом о трате считать исчезновение данного входа из списка непотраченных выходов.
@awoland ты совсем не понимаешь проблемы?
У меня, а так же и у бирж btc-e, bitstamp, kraken и itbit никаких проблем нет. Проблемы есть лишь у гокса и подобным им "умникам", которые считают себя умнее остальных и не прислушиваются к советам и рекомендациям компетентных специалистов (авторов-разработчиков) протокола.Quote
Как ты пометишь у себя что созданный тобой перевод подтвердился сетью и деньги ушли? Я говорю про автоматизированные средства выплат с тысячами транзакций в час, а не ручную обработку трех в месяц!
Выше вам уже ответили: нужно проверять входы-выходы транзакций (подписи скриптов). Эти вещи без приватных ключей изменить невозможно.@awoland ты совсем не понимаешь проблемы?
Ты создаешь исходящую транзакцию, по всем правилам валидную, с комиссией и т.п., но тут же после у тебя появляется в кошельке еще одна транзакция, которую ты не делал, подтверждается сетью и списывает точно такую же сумму на те же адреса что ты указал, а твоя транзакция так и не добавляется в блокчейн.
Как ты пометишь у себя что созданный тобой перевод подтвердился сетью и деньги ушли? Я говорю про автоматизированные средства выплат с тысячами транзакций в час, а не ручную обработку трех в месяц!
Входы-выходы и суммы не меняются, наверняка что-то еще уникальное.. делай проверку по этому. Ты создаешь исходящую транзакцию, по всем правилам валидную, с комиссией и т.п., но тут же после у тебя появляется в кошельке еще одна транзакция, которую ты не делал, подтверждается сетью и списывает точно такую же сумму на те же адреса что ты указал, а твоя транзакция так и не добавляется в блокчейн.
Как ты пометишь у себя что созданный тобой перевод подтвердился сетью и деньги ушли? Я говорю про автоматизированные средства выплат с тысячами транзакций в час, а не ручную обработку трех в месяц!
@awoland ты совсем не понимаешь проблемы?
Ты создаешь исходящую транзакцию, по всем правилам валидную, с комиссией и т.п., но тут же после у тебя появляется в кошельке еще одна транзакция, которую ты не делал, подтверждается сетью и списывает точно такую же сумму на те же адреса что ты указал, а твоя транзакция так и не добавляется в блокчейн.
Как ты пометишь у себя что созданный тобой перевод подтвердился сетью и деньги ушли? Я говорю про автоматизированные средства выплат с тысячами транзакций в час, а не ручную обработку трех в месяц!
Ты создаешь исходящую транзакцию, по всем правилам валидную, с комиссией и т.п., но тут же после у тебя появляется в кошельке еще одна транзакция, которую ты не делал, подтверждается сетью и списывает точно такую же сумму на те же адреса что ты указал, а твоя транзакция так и не добавляется в блокчейн.
Как ты пометишь у себя что созданный тобой перевод подтвердился сетью и деньги ушли? Я говорю про автоматизированные средства выплат с тысячами транзакций в час, а не ручную обработку трех в месяц!
Гокс по ходу крысы.
Всё это высасано из пальца, чтобы биточки увести.
Всё это высасано из пальца, чтобы биточки увести.
Что вы всё жуете это "вчерашнее сено"? Сказали вам уже давно, что подтверждением транзакции является включение её в блокчейн (и +5 блоков после). Не нужно смотреть на транзакции пока они висят в буфере неподтверждённых. И не будет никаких проблем. А если мчудаки с Гокса уверовали в то, что они умнее всех, то это их собственные религиозные проблемы и, в таком случае, они ССЗБ...
Внезапно, блин! Полностью согласен с rPmanом — это баг. Несколько часов назад столкнулся: переводил битки с одного своего кошелька на другой, транзакция в другом кошельке отобразилась, но почему-то id у неё был другой относительно отправленной. Тупил несколько минут, потом дошло. К моменту подтверждения новая транзакция перекрыла старую и в первом кошельке.
И всё бы ничего — сумма переведённого и получатели никак не могли измениться, только вот с таким design flaw эту схему (и вообще схемы с refund transaction) безопасно для пользователя реализовать не получится — недобросовестный залогоприниматель сможет навсегда заблокировать залоговые средства (ценой потери репутации, конечно).
P.S. К сожалению, первую транзакцию не сохранил, а после перекрытия она из кошелька удалилась, так что сказать, что именно было изменено, не могу.
И всё бы ничего — сумма переведённого и получатели никак не могли измениться, только вот с таким design flaw эту схему (и вообще схемы с refund transaction) безопасно для пользователя реализовать не получится — недобросовестный залогоприниматель сможет навсегда заблокировать залоговые средства (ценой потери репутации, конечно).
P.S. К сожалению, первую транзакцию не сохранил, а после перекрытия она из кошелька удалилась, так что сказать, что именно было изменено, не могу.
Вы понимаете что такое транзакции в bitcoin? это не перевести деньги от А до Б, это программа на языке forth.
Стандартизация была в очень старых версиях, для простоты реализации, и уже убрана, чтобы позволить такие веселые вещи как merged mining или multisig и много чего в будущем, о чем мы не догадываемся!
Стандартизация была в очень старых версиях, для простоты реализации, и уже убрана, чтобы позволить такие веселые вещи как merged mining или multisig и много чего в будущем, о чем мы не догадываемся!
Интересный баг!
Исправить со стороны bitcoin почти нереально (нарушится совместимость), можно только сделать для себя пометку 'так не делать', но это заметно усложняет код работы с исходящими транзакциями на сервисах, потому что потребует заводить свои идентификаторы, основанные хотя бы на используемых в транзакции входах. Как вариант, добавить этот функционал в rpc bitcoind, в виде дополнительного поля, например inputhash.
"Исправить" вполне реально. Нужно стандартизировать формат транзакций, а все транзакции, отклоняющиеся от формата (неканоничные подписи, например), сделать нестандартными.Исправить со стороны bitcoin почти нереально (нарушится совместимость), можно только сделать для себя пометку 'так не делать', но это заметно усложняет код работы с исходящими транзакциями на сервисах, потому что потребует заводить свои идентификаторы, основанные хотя бы на используемых в транзакции входах. Как вариант, добавить этот функционал в rpc bitcoind, в виде дополнительного поля, например inputhash.
В этом случае узлы не будут такие транзакции принимать и передавать другим узлам. Риски снизятся значительно, если пулы примут это изменение.
Это будет так называемый soft-fork.
Насколько мне известно, разработчики референсного клиента уже длительное время работают над этим.
И я почти уверен что близкие к 100% обычных разработчиков сервисов по приему и отправке bitcoin допустили бы ту же самую ошибку - txid не определяет однозначно твою транзакцию.
Будь я разработчиком сервиса и если передо мной встала бы задача проверки отправленного, то я бы вычитал все источники про txid, чтобы убедиться в ее безопасности использования. Тем более товарищи ваяли собственную реализацию кошелька. Так что я склонен думать, что это все же фейл гокса. Интересный баг!
Исправить со стороны bitcoin почти нереально (нарушится совместимость), можно только сделать для себя пометку 'так не делать', но это заметно усложняет код работы с исходящими транзакциями на сервисах, потому что потребует заводить свои идентификаторы, основанные хотя бы на используемых в транзакции входах. Как вариант, добавить этот функционал в rpc bitcoind, в виде дополнительного поля, например inputhash.
Исправить со стороны bitcoin почти нереально (нарушится совместимость), можно только сделать для себя пометку 'так не делать', но это заметно усложняет код работы с исходящими транзакциями на сервисах, потому что потребует заводить свои идентификаторы, основанные хотя бы на используемых в транзакции входах. Как вариант, добавить этот функционал в rpc bitcoind, в виде дополнительного поля, например inputhash.
похоже это не баг а особенность, которую не учли гоксовцы.
также следует учитывать что хеш создаваемой транзакции можно изменить только до включения в блокчейн, тоесть до получения первого подтверждения (включения в блок).
что получилось - получилось что система вывода у гокса для проверки прохождения операции использовались данные которые могут быть изменены - это не проблема биткоина, это проблема конкретно разработчиков системы вывода гокса. Как минимум им достаточно было факт прохождения операций проверять не только по одному хешу а еще и поступлениям на адресс вывода.
Отличную аналогию могу привести ошибка при проектирование антены в одной из последних моделей айфона, и аргументы против - 'вы не правильно держите телефон'.
И как обычно, виновника либо сложно найти либо тупое 'сам дурак', не достаточно для того чтобы понять и забыть.
Я, к примеру, хоть и поглядываю на bitcoin с точки зрения проектировщика и разработчика сервисов, не знал и не догадывался о такой особенности 'протокола', и даже тот факт что это было опубликовано аж в 2011 не спасает положение (но урок мне, нужно больше читать англоязычных источников). И я почти уверен что близкие к 100% обычных разработчиков сервисов по приему и отправке bitcoin допустили бы ту же самую ошибку - txid не определяет однозначно твою транзакцию.
ждемс
Jump to: