Topic: double spendinng - дважды послать (Read 1798 times)

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

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

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

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

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

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

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

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

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

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

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

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

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

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