только вот нету там алгоритма а лезть к ним на сайт за каждой транзакцией как-то не катит
Этот алгоритм очевиден, его только надо воплотить в коде.а в новокоине уже внутри кошелька вводят metahash
Topic: Руководство по уязвимым сделкам: что озна
 (Read 2146 times)
а в новокоине уже внутри кошелька вводят metahash
только вот нету там алгоритма а лезть к ним на сайт за каждой транзакцией как-то не катит
Этот алгоритм очевиден, его только надо воплотить в коде. hashtontxid/TxHash - Convert a transaction hash to ntxid
ntxidtohash/nTxID - Convert an ntxid to transaction hash
вот это дело!
только вот нету там алгоритма а лезть к ним на сайт за каждой транзакцией как-то не катит
Ну да, «стандартизировали» – это я громко выразился. Но по крайней мере сделали общеизвестный алгоритм и API с возможностью проверки «правильного» хэша. От этого можно плясать.
О, это уже стандартизировали? Прелестно, благодарю за информацию.
Ну, blockchain.info — это вроде ещё не стандарт. За развитием стандарта наблюдать лучше здесь.
О, это уже стандартизировали? Прелестно, благодарю за информацию.
Quote
Кроме того, если у нас нормальный клиент, а не голая система слежения за транзакциями, то необязательно это делать для всех транзакций, пришедших в блоке, достаточно такую операцию производить лишь для всех новых транзакций из listtransactions.
А я о том же. По расписанию или по событию ловить новые транзакции и отрабатывать. Просто каждую транзакцию в пришедшем блоке пропустить через функцию вычисления «правильного» TXID (назовём это TXID2, чтоб н̶и̶к̶т̶о̶ ̶н̶е̶ ̶д̶о̶г̶а̶д̶а̶л̶с̶я̶ не путаться), и искать это в базе.
В терминах blockchain.info это называется "normalized hash":Quote from: https://blockchain.info/q/
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. 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
1. Ни фига, я так уже делал – баланс изменяется только у лицевого счёта (при использовании «sendfrom», разумеется). Можно переводить и между счетами. Главное – следить, чтоб баланс счёта не уходил в минус. Хотя это уже особенности сервиса – мабуть, вы хотите кредиты выдавать.
2. Да никакого кошмара же. Просто каждую транзакцию в пришедшем блоке пропустить через функцию вычисления «правильного» TXID (назовём это TXID2, чтоб н̶и̶к̶т̶о̶ ̶н̶е̶ ̶д̶о̶г̶а̶д̶а̶л̶с̶я̶ не путаться), и искать это в базе. А bitcoind вам не свяжет оригинальную транзакцию с модифицированной по TXID.
То есть нужна пара функций типа «tTransaction parse_transaction(tTXID txid)» и «tTXID2 generate_txid2(tTransaction transaction)». Первая возвращает разобранную транзакцию по TXID в виде объекта, вторая считает TXID2 по этому объекту. Пришёл блок – парсим все транзакции в нём, считаем TXID2 для каждой – и искать в базе. Что ужасного-то?
2. Да никакого кошмара же. Просто каждую транзакцию в пришедшем блоке пропустить через функцию вычисления «правильного» TXID (назовём это TXID2, чтоб н̶и̶к̶т̶о̶ ̶н̶е̶ ̶д̶о̶г̶а̶д̶а̶л̶с̶я̶ не путаться), и искать это в базе. А bitcoind вам не свяжет оригинальную транзакцию с модифицированной по TXID.
То есть нужна пара функций типа «tTransaction parse_transaction(tTXID txid)» и «tTXID2 generate_txid2(tTransaction transaction)». Первая возвращает разобранную транзакцию по TXID в виде объекта, вторая считает TXID2 по этому объекту. Пришёл блок – парсим все транзакции в нём, считаем TXID2 для каждой – и искать в базе. Что ужасного-то?
Вот вы и пытаетесь наступить на те же грабли, т.е. использовать хэш двоичного представления транзакции в качестве её идентификатора...
Навскидку альтернативы:
• используйте лицевые счета (accounts) API bitcoind. Грубо говоря, эта штука позволяет поделить общий кошелёк на кармашки, и в каждом кармашке держать свою сумму. TXID здесь вообще не нужны, человек вводит-выводит свои средства и сразу видит сумму лицевого счёта, всем остальным занимаетcя bitcoind. Недостатки: использование bitcoind, который для очень больших нагрузок не очень хорош.
• генерируйте свой TXID на основt входов, выходов и сумм. Например, парсите транзакцию, у вас получается N входов с суммами и M выходов с суммами, подписи, комиссия и т.п. Сериализируете полученный объект в JSON-строчку (или в любой другой последовательный формат) и считаете хэш от неё. Недостатки: TXID, посчитанный вами, нигде нельзя будет проверить, это будет исключительно ваше, внутреннее представление транзакции.
Навскидку альтернативы:
• используйте лицевые счета (accounts) API bitcoind. Грубо говоря, эта штука позволяет поделить общий кошелёк на кармашки, и в каждом кармашке держать свою сумму. TXID здесь вообще не нужны, человек вводит-выводит свои средства и сразу видит сумму лицевого счёта, всем остальным занимаетcя bitcoind. Недостатки: использование bitcoind, который для очень больших нагрузок не очень хорош.
• генерируйте свой TXID на основt входов, выходов и сумм. Например, парсите транзакцию, у вас получается N входов с суммами и M выходов с суммами, подписи, комиссия и т.п. Сериализируете полученный объект в JSON-строчку (или в любой другой последовательный формат) и считаете хэш от неё. Недостатки: TXID, посчитанный вами, нигде нельзя будет проверить, это будет исключительно ваше, внутреннее представление транзакции.
1. способ не подходит так как если взять средства с кошелька то он со всех аккаунтов без разбора возьмет входы оставшиеся и балансы у всех уменьшатся. использовать lock или move вообще дурдом - если сделать рескан или еще чего балансы так же собьются. вообще использование аккаунтов в кошельке - это большая ошибка.
2. это вообще кошмар - каждую такую штуку потом вручную искать в каждом новом блоке?? ведь эту работу уже сделал "подвинутый" кошелек.. как у него через АПИ узнать/получить инфо об этом?
Вот вы и пытаетесь наступить на те же грабли, т.е. использовать хэш двоичного представления транзакции в качестве её идентификатора...
Навскидку альтернативы:
• используйте лицевые счета (accounts) API bitcoind. Грубо говоря, эта штука позволяет поделить общий кошелёк на кармашки, и в каждом кармашке держать свою сумму. TXID здесь вообще не нужны, человек вводит-выводит свои средства и сразу видит сумму лицевого счёта, всем остальным занимаетcя bitcoind. Недостатки: использование bitcoind, который для очень больших нагрузок не очень хорош.
• генерируйте свой TXID на основt входов, выходов и сумм. Например, парсите транзакцию, у вас получается N входов с суммами и M выходов с суммами, подписи, комиссия и т.п. Сериализируете полученный объект в JSON-строчку (или в любой другой последовательный формат) и считаете хэш от неё. Недостатки: TXID, посчитанный вами, нигде нельзя будет проверить, это будет исключительно ваше, внутреннее представление транзакции.
Навскидку альтернативы:
• используйте лицевые счета (accounts) API bitcoind. Грубо говоря, эта штука позволяет поделить общий кошелёк на кармашки, и в каждом кармашке держать свою сумму. TXID здесь вообще не нужны, человек вводит-выводит свои средства и сразу видит сумму лицевого счёта, всем остальным занимаетcя bitcoind. Недостатки: использование bitcoind, который для очень больших нагрузок не очень хорош.
• генерируйте свой TXID на основt входов, выходов и сумм. Например, парсите транзакцию, у вас получается N входов с суммами и M выходов с суммами, подписи, комиссия и т.п. Сериализируете полученный объект в JSON-строчку (или в любой другой последовательный формат) и считаете хэш от неё. Недостатки: TXID, посчитанный вами, нигде нельзя будет проверить, это будет исключительно ваше, внутреннее представление транзакции.
Да не надо вам ничего запоминать, клиент всё сделает за вас. Естественно, нормальный клиент, а не такой, который запоминает только TXID.
Блок, в который попадёт изменённая транзакция, дойдёт и до вашего клиента, и будет в нём видна.
Пользуйтесь оригинальным клиентом или другим, который знает о transaction malleability, и не будет проблем.
В который раз говорю: у гокса была своя реализация клиента, они про transaction malleability забыли или не стали париться по этому поводу. Вот и результат. Если они, конечно, правду говорят, что их поимели этим методом...
Блок, в который попадёт изменённая транзакция, дойдёт и до вашего клиента, и будет в нём видна.
Пользуйтесь оригинальным клиентом или другим, который знает о transaction malleability, и не будет проблем.
В который раз говорю: у гокса была своя реализация клиента, они про transaction malleability забыли или не стали париться по этому поводу. Вот и результат. Если они, конечно, правду говорят, что их поимели этим методом...
еще раз:
через АПИ даю команду перевести монеты и в ответ получаю ТХ_ИД которую запоминаю в своей БД
транзакцию кошелек шлет в сеть, там ее ТХ_ИД меняют и засовывают в блок
(а в моей базе данных лежит неизмененый ТХ_ИД)
даже пусть кошелек мой продвинутый и понял что в пришедшем блоке ТХ_ИД другой и для этой транзакции сам ее обновил...
но в моей базе данных то эта транзакция осталась у меня со старым ТХ_ИД...
тоесть мне тоже по пришествии блока смотреть свою транзакцию через АПИ кошелька и присваивать ей новый ТХ_ИД ??
тогда по старому ТХ_ИД я через АПИ смогу получить новый ТХ_ИД этой транзакции?? скорее всего нет - кошелек выдаст ошибку - мол такой транзакции нету...
Да не надо вам ничего запоминать, клиент всё сделает за вас. Естественно, нормальный клиент, а не такой, который запоминает только TXID.
Блок, в который попадёт изменённая транзакция, дойдёт и до вашего клиента, и будет в нём видна.
Пользуйтесь оригинальным клиентом или другим, который знает о transaction malleability, и не будет проблем.
В который раз говорю: у гокса была своя реализация клиента, они про transaction malleability забыли или не стали париться по этому поводу. Вот и результат. Если они, конечно, правду говорят, что их поимели этим методом...
Блок, в который попадёт изменённая транзакция, дойдёт и до вашего клиента, и будет в нём видна.
Пользуйтесь оригинальным клиентом или другим, который знает о transaction malleability, и не будет проблем.
В который раз говорю: у гокса была своя реализация клиента, они про transaction malleability забыли или не стали париться по этому поводу. Вот и результат. Если они, конечно, правду говорят, что их поимели этим методом...
спасибо вас понял!
если в базе у меня есть сумма выплат и адрес куда ушла эта сумма + для быстрого поиска ТХ_ИД (но нету блока в который она включена), то:
?? если мне сказали что мой ТХ_ИД в блок не включен (но включен другой ТХ_ИД с этими же выплатами и входами), то меня могут развести, так как мой кошелек покажет что действительно такая транзакция с 0 подтверждениями... но на самом деле мои входы уже ушли на эти выходы, просто в блоке они имеют другой ТХ_ИД
блин как с этим мне бороться? запоминать дату создания транзакции и сумму выхода + адрес выхода? что-то много инфо получается надо хранить в базе данных...
или чистить ее каждый раз когда она включена в блок и получила скажем 3 подтверждения?
если в базе у меня есть сумма выплат и адрес куда ушла эта сумма + для быстрого поиска ТХ_ИД (но нету блока в который она включена), то:
?? если мне сказали что мой ТХ_ИД в блок не включен (но включен другой ТХ_ИД с этими же выплатами и входами), то меня могут развести, так как мой кошелек покажет что действительно такая транзакция с 0 подтверждениями... но на самом деле мои входы уже ушли на эти выходы, просто в блоке они имеют другой ТХ_ИД
блин как с этим мне бороться? запоминать дату создания транзакции и сумму выхода + адрес выхода? что-то много инфо получается надо хранить в базе данных...
или чистить ее каждый раз когда она включена в блок и получила скажем 3 подтверждения?
ну а как тогда у себя в базе запоминать транзакцию?
вот я получил с кошелька транзакцию что деньги пришли и запомнил ее в базе по ТХ_ИД + ВОУТ
и как меня могут обмануть?
Транзакция – это набор входов и выходов с суммами. TXID в ней вообще не нужен, он применяется до попадания транзакции в блоки для того, чтобы узел, которому от другого пришла транзакция, мог быстро понять, новая она или уже имеется во вре́менном хранилище транзакций. И быстро удалять их из временного хранилища, когда она попадает в блок. По сути это вре́менная штука.вот я получил с кошелька транзакцию что деньги пришли и запомнил ее в базе по ТХ_ИД + ВОУТ
и как меня могут обмануть?
Вас обмануть таким образом не могут. Могут обмануть отправителя, да и то только того, кто считает, что транзакция непременно попадёт в блоки в том виде, в котором он её сгенерировал (и не глядя повторит транзакцию, если не найдёт её в блоках, и ещё при этом случится так, что входы все не потрачены за предыдущий раз). А этого никто не гарантирует в сети биткойн. Гарантируется (и подписывается приватными ключами) только результат транзакции, а не её двоичное представление, скажем так.
Если надо ключик для локальной базы – соберите времянку из входов и выходов с суммами, а также временем её прихода – она с очень высокой вероятностью будет уникальной. Можно прохешировать её для унификации размера, но тут можно напороться на коллизию...
вот я получил с кошелька транзакцию что деньги пришли и запомнил ее в базе по ТХ_ИД + ВОУТ
и как меня могут обмануть?
Получателя никак не могут обмануть. Только невнимательного отправителя. и как меня могут обмануть?
ну а как тогда у себя в базе запоминать транзакцию?
вот я получил с кошелька транзакцию что деньги пришли и запомнил ее в базе по ТХ_ИД + ВОУТ
и как меня могут обмануть?
вот я получил с кошелька транзакцию что деньги пришли и запомнил ее в базе по ТХ_ИД + ВОУТ
и как меня могут обмануть?
Совершенно верно, да и публичный ключ не нужен. Фишка в том, что TXID и есть хэш всех данных транзакции.
Но проблема будет только у тех, кто однозначно привязал внутреннюю транзакцию к TXID и отслеживает успешность только по нему, что, видимо, и было у гокса. В референсном коде это давно пофиксили. Да и не было это особой проблемой, биткойны таким образом невозможно увести.
как долго мы вас ждали, спасибо за разьяснения... очень лаконично... и для всех Но проблема будет только у тех, кто однозначно привязал внутреннюю транзакцию к TXID и отслеживает успешность только по нему, что, видимо, и было у гокса. В референсном коде это давно пофиксили. Да и не было это особой проблемой, биткойны таким образом невозможно увести.
я спросил кто может добавить? тот кто не имеет секретного ключа?
тоесть получил на входе транзакцию, поменял ее (имея только публичный ключ), создал новый хеш и ТХ_ИД и ретранслировал в сеть дальше - так чтоли?
Да, именно так. "Гибкость" или "ковкость" транзакций позволяет поменять транзакцию так, что ее смысл останется тем же, а хеш изменится.тоесть получил на входе транзакцию, поменял ее (имея только публичный ключ), создал новый хеш и ТХ_ИД и ретранслировал в сеть дальше - так чтоли?
Для этого вообще никакой криптографии не надо знать - ни приватных, ни публичных ключей
Так как об этом написано уже в 100500 местах с примерами - я еще один раз объяснять не буду.
Совершенно верно, да и публичный ключ не нужен. Фишка в том, что TXID и есть хэш всех данных транзакции.
Но проблема будет только у тех, кто однозначно привязал внутреннюю транзакцию к TXID и отслеживает успешность только по нему, что, видимо, и было у гокса. В референсном коде это давно пофиксили. Да и не было это особой проблемой, биткойны таким образом невозможно увести.
Но проблема будет только у тех, кто однозначно привязал внутреннюю транзакцию к TXID и отслеживает успешность только по нему, что, видимо, и было у гокса. В референсном коде это давно пофиксили. Да и не было это особой проблемой, биткойны таким образом невозможно увести.
я спросил кто может добавить? тот кто не имеет секретного ключа?
тоесть получил на входе транзакцию, поменял ее (имея только публичный ключ), создал новый хеш и ТХ_ИД и ретранслировал в сеть дальше - так чтоли?
тоесть получил на входе транзакцию, поменял ее (имея только публичный ключ), создал новый хеш и ТХ_ИД и ретранслировал в сеть дальше - так чтоли?
Jump to: