double spendinng - дважды послать

[icreator]

http://coinspot.ru/news/eksperimentalnaya-ataka-na-bystrye-bitkoin-platezhi/

Разумеется, определённое решение было придумано и в системе Биткоин. Пользователи подписывают все свои транзакции, а за их целостностью следит специальный сервис, который также осуществляет простановку времени в цепочках операций («timestamping»), делая такую статистику доступной всем пользователям сети. Но в случае т.н. быстрых платежей, когда после оплаты проходит менее 30 секунд, в течении которых пользователь может получить услугу и забрать, например, наличные из банкомата, проверить факт двойной оплаты невозможно. До недавнего времени официальная позиция разработчика сети Биткоин состояла в том, что при оплате мелких услуг следует игнорировать такую опасность — считалось, что стоимость атаки такого рода намного превзойдёт возможную прибыль. Хотя не было дано оценок параметров таких атак и было неясно насколько они реализуемы.

Исследователи Ghassan O. Karame (Европейская лаборатория NEC), El li Androulaki и Srdjan Capkun (Швейцарская высшая техническая школа Цюриха) впервые вывели точные оценки условий атаки двойного размещения на быстрые платежи и провели экспериментальные атаки. Они использовали только свои собственные кошельки в системе, чтобы не наносить финансового ущерба пользователям, не вовлечённым в исследование. Как оказалось, для предотвращения атаки в текущем протоколе Биткоин период ожидания заверенной транзакции был чрезвычайно большим (до нескольких десятков минут), что недопустимо для быстрых платежей и такие платежи практически не имеют защиты от двойной оплаты. При этом, как оказалось, атака не стоит противнику практически никаких вычислительных затрат и сводится лишь к попыткам перебора соединений.

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

[RoadTrain]

Сейчас референсный клиент отвергает дабл-спенд транзакции, не принимает в mempool.
На этом основана "надежность" транзакций без подтверждений. Что пулы, получив первую транзакцию, вторую уже не примут.

В действительности атаку провести можно совершенно без мощностей. Нужно лишь выяснить ip-адреса узлов крупных пулов и того сервиса, который нужно атаковать. Либо адреса ближайших к ним узлов.
Затем скормить им одновременно две разные транзакции. То есть тут эксплуатируются особенности топологии сети.

[Grigorjevi4]

Всегда удивляло что никто никогда не придавал этому особого значения. Как SD начали даблспендить - чуть пошумели и успокоились.

[icreator]

Сейчас референсный клиент отвергает дабл-спенд транзакции, не принимает в mempool.
На этом основана "надежность" транзакций без подтверждений. Что пулы, получив первую транзакцию, вторую уже не примут.

В действительности атаку провести можно совершенно без мощностей. Нужно лишь выяснить ip-адреса узлов крупных пулов и того сервиса, который нужно атаковать. Либо адреса ближайших к ним узлов.
Затем скормить им одновременно две разные транзакции. То есть тут эксплуатируются особенности топологии сети.

я так понимаю что суть в том чтоЖ
1. на кошель магазина прислать транзакцию №1 - его ноду зацепить к своему кошельку чтобы к нему пришла транзакция быстро. магазин примет к оплате эту транзакцию. кошелек свой запускать на сервере физически рядом с магазином - скажем в европе или штатах.

2. из копии кшелька, размещенного физически в другом месте, послать 2ю транзакцию в которой эти монеты отсылаются на свой адрес напрямую на 3-4 пула которые имеют 70-80% мощности сети.

так может получиться ситуация что 1я транзакция будет первой в кошельке магазина а 2я транзакция будет первой в mempool пулов и она войдет в блок подтвержденной - можно так у буржуев укасть битки?

[Balthazar]

Со стороны сервиса это уже сейчас решается привлечением посредников, в числе которых есть и пулы.

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

[icreator]

Со стороны сервиса это уже сейчас решается привлечением посредников, в числе которых есть и пулы.

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

спасибо - я понял!
то есть пул не будет ретранслировать дальше "плохую" транзакцию
получается рипле не имеет никаких преимуществ перед биткоином

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

или есть команда в АПИ принимать только от них... или это надо на уровне своей сети фильтр какойто задавать?
-connect  видимо не подойдет?
-bind=<addr>

[Balthazar]

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

В API команд нет, можно модифицировать клиент или просто указать в connect список найденных нод пулов. Входящие соединения, ircseed и dnsseed при этом необходимо отключить.

[icreator]

тоесть просто задать несколько коннектов к "доверенным пулам" и они сами отфильтруют все?
а кроме -connect что-то еще нужно задавать?
если все начнут так к пулам цепляться у них не хватит на всех maxconnections
может нужно что-то вроде listen? или коннект как раз и будет слушать только тот ИП?

и как узнать что все 3 пула эту транзакцию включили в свой mempool?

[Balthazar]

Если не собираешься проверять, что транзакция включена в пул всеми тремя, то просто список для connect указывать и все.

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

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

Короче, или просто (использовать пулы как фильтр, ничего менять не нужно) или посложнее (делать ручную проверку содержимого mempool) в зависимости от градуса паранойи.

[icreator]

эээ
а разве я могу сделать запрос на пул чужой и узнать что у него в mempool ??

[Balthazar]

Конечно, если там клиент не из каменного века.

https://en.bitcoin.it/wiki/Protocol_specification#mempool

[apxu]

Пытаюсь для себя понять как все работает. Так что простите если вопросы задаю глупые/некорректные

А что если вторая транзакция (говорим о DoubleSpend) идет с большей комиссией, чем первая? В этом случае она будет отвергнута?
Частный случай: первая транзакция была отправлена без комиссии, потом юзер почесал репу и все-таки решил не ждать N часов доброго майнера, а заплатить копейку чтоб транзакция попала в ближайший блок.

[nocoin]

Пытаюсь для себя понять как все работает. Так что простите если вопросы задаю глупые/некорректные

А что если вторая транзакция (говорим о DoubleSpend) идет с большей комиссией, чем первая? В этом случае она будет отвергнута?
Частный случай: первая транзакция была отправлена без комиссии, потом юзер почесал репу и все-таки решил не ждать N часов доброго майнера, а заплатить копейку чтоб транзакция попала в ближайший блок.

Если юзер успел почесать репу, его первая транзакция уже разошлась по всей сети и вторую никто не примет.
В этой теме обсуждается ситуация, когда мы одновременно отправляем транзакцию №1 в магазин, а транзакцию №2 в крупные пулы с надеждой на то, что магазин примет первую и отвергнет вторую, а пулы сделают наоборот. Магазин посчитает, что всё ок и выдаст товар, но выгодная для него транзакция №1 в блок не попадёт, а попадёт №2.

[apxu]

Если юзер успел почесать репу, его первая транзакция уже разошлась по всей сети и вторую никто не примет.

Вам не кажется, что тут есть проблема с деньгами, зависающими на потенциально неопределенное/бесконечное время?

Допустим, я отправляю транзакцию с недостаточной комиссией для включения в блок (мы уже в той реальности, где транзакций настолько много, что майнеры включают в блок только самые выгодные транзакции). В результате - транзакция подвисает, сдачей с неё я тоже воспользоваться не могу. И получится, что я "повесив" платеж на рубль в результате блокирую весь свой счет на котором 100500 денег?

Не является ли в этом случае правильным алгоритмом для майнера в случае "конкурирующих" транзакций отвергать не вторую по порядку прихода, а менее выгодную? И да, в этом случае возможен "обман" магазинов, отпускающих товар до первого подтверждения.

[icreator]

Пытаюсь для себя понять как все работает. Так что простите если вопросы задаю глупые/некорректные

А что если вторая транзакция (говорим о DoubleSpend) идет с большей комиссией, чем первая? В этом случае она будет отвергнута?
Частный случай: первая транзакция была отправлена без комиссии, потом юзер почесал репу и все-таки решил не ждать N часов доброго майнера, а заплатить копейку чтоб транзакция попала в ближайший блок.

Если юзер успел почесать репу, его первая транзакция уже разошлась по всей сети и вторую никто не примет.
В этой теме обсуждается ситуация, когда мы одновременно отправляем транзакцию №1 в магазин, а транзакцию №2 в крупные пулы с надеждой на то, что магазин примет первую и отвергнет вторую, а пулы сделают наоборот. Магазин посчитает, что всё ок и выдаст товар, но выгодная для него транзакция №1 в блок не попадёт, а попадёт №2.

на одном пуле не может 2-е транзакции, использующих один и тот же вход монет в memopool затесаться ведь так?
запишется только первая по времени поступления? не зависимо от комиссии видимо

а если на одном пуле №1 транзакция в мемо-пул а на другом №2 ? они ведь обмениваются меж собой данными - они не смогут разобраться какая из них "правильная"?? так чтобы на них 2-хх была только одна и таже транзакция

[nocoin]

Допустим, я отправляю транзакцию с недостаточной комиссией для включения в блок (мы уже в той реальности, где транзакций настолько много, что майнеры включают в блок только самые выгодные транзакции). В результате - транзакция подвисает, сдачей с неё я тоже воспользоваться не могу. И получится, что я "повесив" платеж на рубль в результате блокирую весь свой счет на котором 100500 денег?

Почему-то мне кажется, что транзакция не будет храниться в сети вечно. Разумно предположить, что mempool периодически очищается, чтобы не забивать память. Могу ошибаться, лень исходники смотреть.

[Balthazar]

Подумали-подумали и надумали, как это решить:

https://bitcointalk.org/index.php?topic=143221.msg4413148#msg4413148

Ну если не решить, то хотя бы существенно затруднить. В Proof-of-Work системе сделать подобное большая проблема, ну а в Proof-of-Stake делается без вопросов...

[apxu]

В Proof-of-Work системе сделать подобное большая проблема

А можно все-таки по-русски пояснить, как эта ситуация происходит в нынешнем биткоине (а не в нова)?

если клиент видит транзакцию, которая по своим инпутам противоречит его чейну (данным в блоках) - он просто игнорирует ее.
с этим все ясно.

1) что делают обычные клиенты, увидев "вторую транзакцию", которая противоречит уже имеющейся в неподтвержденном пуле?
2) что делает майнер? Имеет ли право майнер взять из двух транзакций наиболее выгодную, а первую "забыть"?

заодно еще сопутствующий вопрос:
3) что делает клиент, отправивший транзакцию? в интернетах говоритя о том, что пока она не включена в блок, bitcoin-d пытается ее перепослать? как часто? сколько времени? пытаются ли то же самое сделать пиры, которые получили эту транзакцию?

ЗЫ. я не собираюсь (хотя вы мне не поверите все равно) обманывать получателей таким образом. хочется понять как работает сеть

[Balthazar]

Все клиенты отклоняют конфликтующие транзакции. Майнер может выбрать ту транзакцию, которая ему нравится, но как правило оперирует тем что лежит в пуле транзакций.

То есть тут все хорошо, если бы не одно но. Суть его в том, что все P2P сети имеют определенный показатель латентности, создающий временное окно, в котором возможна отправка конфликтующих транзакций. И тут главное не просто отправить, а выбрать кому отправить.

Если отправить в пределах такого окна одну транзакцию жертве, а другую на пул, то произойдет следующее:

1) Жертва примет транзакцию в свой пул и будет ждать подтверждений;
2) Пул примет вторую транзакцию и включит ее в свою работу;
3) Пул не примет транзакцию, предназначавшуюся жертве, потому что посчитает ее конфликтом;
4) Жертва не примет транзакцию, посланную на пул, потому что посчитает ее конфликтом;
5) Если пул занимает большую часть мощности сети, то высок шанс того, что он подтвердит вторую транзакцию и жертва останется ни с чем.

[apxu]

[skip]
5) Если пул занимает большую часть мощности сети, то высок шанс того, что он подтвердит вторую транзакцию и жертва останется ни с чем.

Да это все уже выше по тексту изжевано несколько раз.
Меня с точки зрения протокола интересует логика пересылок. Простите, что отхожу от темы топика

Допустим, мы знаем (хотя как мы это узнаем?) IP мерчанта (а у него может не быть открытого порта) и можем атаковать его "напрямую", подсовывая ему "первую" транзакцию, а на 100500 других адреов тут же отправляем "вторую" конфликтующую с первой.

Какова существующая скорость распространения транзакций по сети? Правильно ли я понимаю, что каждый клиент получив от своего пира новую транзакцию сразу же после валидации без задержек рассылает ее всем своим соседям? Или какой-то другой алгоритм?
Получает ли клиент от своего пира какую-либо нотификацию - "ок, принял твою транзакцию, ща разошлю дальше" или "не, ты мне прислал противоречащее моим убеждениям, я это игнорирую"