То есть тут все хорошо, если бы не одно но. Суть его в том, что все P2P сети имеют определенный показатель латентности, создающий временное окно, в котором возможна отправка конфликтующих транзакций. И тут главное не просто отправить, а выбрать кому отправить.
Стоит это выделить. 
Topic: double spendinng - дважды послать (Read 1798 times)
[skip]
5) Если пул занимает большую часть мощности сети, то высок шанс того, что он подтвердит вторую транзакцию и жертва останется ни с чем.
Да это все уже выше по тексту изжевано несколько раз.5) Если пул занимает большую часть мощности сети, то высок шанс того, что он подтвердит вторую транзакцию и жертва останется ни с чем.
Меня с точки зрения протокола интересует логика пересылок. Простите, что отхожу от темы топика
Допустим, мы знаем (хотя как мы это узнаем?) IP мерчанта (а у него может не быть открытого порта) и можем атаковать его "напрямую", подсовывая ему "первую" транзакцию, а на 100500 других адреов тут же отправляем "вторую" конфликтующую с первой.
Какова существующая скорость распространения транзакций по сети? Правильно ли я понимаю, что каждый клиент получив от своего пира новую транзакцию сразу же после валидации без задержек рассылает ее всем своим соседям? Или какой-то другой алгоритм?
Получает ли клиент от своего пира какую-либо нотификацию - "ок, принял твою транзакцию, ща разошлю дальше" или "не, ты мне прислал противоречащее моим убеждениям, я это игнорирую"
Все клиенты отклоняют конфликтующие транзакции. Майнер может выбрать ту транзакцию, которая ему нравится, но как правило оперирует тем что лежит в пуле транзакций.
То есть тут все хорошо, если бы не одно но. Суть его в том, что все P2P сети имеют определенный показатель латентности, создающий временное окно, в котором возможна отправка конфликтующих транзакций. И тут главное не просто отправить, а выбрать кому отправить.
Если отправить в пределах такого окна одну транзакцию жертве, а другую на пул, то произойдет следующее:
1) Жертва примет транзакцию в свой пул и будет ждать подтверждений;
2) Пул примет вторую транзакцию и включит ее в свою работу;
3) Пул не примет транзакцию, предназначавшуюся жертве, потому что посчитает ее конфликтом;
4) Жертва не примет транзакцию, посланную на пул, потому что посчитает ее конфликтом;
5) Если пул занимает большую часть мощности сети, то высок шанс того, что он подтвердит вторую транзакцию и жертва останется ни с чем.
То есть тут все хорошо, если бы не одно но. Суть его в том, что все P2P сети имеют определенный показатель латентности, создающий временное окно, в котором возможна отправка конфликтующих транзакций. И тут главное не просто отправить, а выбрать кому отправить.
Если отправить в пределах такого окна одну транзакцию жертве, а другую на пул, то произойдет следующее:
1) Жертва примет транзакцию в свой пул и будет ждать подтверждений;
2) Пул примет вторую транзакцию и включит ее в свою работу;
3) Пул не примет транзакцию, предназначавшуюся жертве, потому что посчитает ее конфликтом;
4) Жертва не примет транзакцию, посланную на пул, потому что посчитает ее конфликтом;
5) Если пул занимает большую часть мощности сети, то высок шанс того, что он подтвердит вторую транзакцию и жертва останется ни с чем.
В Proof-of-Work системе сделать подобное большая проблема
А можно все-таки по-русски пояснить, как эта ситуация происходит в нынешнем биткоине (а не в нова)?если клиент видит транзакцию, которая по своим инпутам противоречит его чейну (данным в блоках) - он просто игнорирует ее.
с этим все ясно.
1) что делают обычные клиенты, увидев "вторую транзакцию", которая противоречит уже имеющейся в неподтвержденном пуле?
2) что делает майнер? Имеет ли право майнер взять из двух транзакций наиболее выгодную, а первую "забыть"?
заодно еще сопутствующий вопрос:
3) что делает клиент, отправивший транзакцию? в интернетах говоритя о том, что пока она не включена в блок, bitcoin-d пытается ее перепослать? как часто? сколько времени? пытаются ли то же самое сделать пиры, которые получили эту транзакцию?
ЗЫ. я не собираюсь (хотя вы мне не поверите все равно) обманывать получателей таким образом. хочется понять как работает сеть
Подумали-подумали и надумали, как это решить:
https://bitcointalksearch.org/topic/m.4413148
Ну если не решить, то хотя бы существенно затруднить. В Proof-of-Work системе сделать подобное большая проблема, ну а в Proof-of-Stake делается без вопросов...
https://bitcointalksearch.org/topic/m.4413148
Ну если не решить, то хотя бы существенно затруднить. В Proof-of-Work системе сделать подобное большая проблема, ну а в Proof-of-Stake делается без вопросов...
Допустим, я отправляю транзакцию с недостаточной комиссией для включения в блок (мы уже в той реальности, где транзакций настолько много, что майнеры включают в блок только самые выгодные транзакции). В результате - транзакция подвисает, сдачей с неё я тоже воспользоваться не могу. И получится, что я "повесив" платеж на рубль в результате блокирую весь свой счет на котором 100500 денег?
Почему-то мне кажется, что транзакция не будет храниться в сети вечно. Разумно предположить, что mempool периодически очищается, чтобы не забивать память. Могу ошибаться, лень исходники смотреть. 
Пытаюсь для себя понять как все работает. Так что простите если вопросы задаю глупые/некорректные
А что если вторая транзакция (говорим о DoubleSpend) идет с большей комиссией, чем первая? В этом случае она будет отвергнута?
Частный случай: первая транзакция была отправлена без комиссии, потом юзер почесал репу и все-таки решил не ждать N часов доброго майнера, а заплатить копейку чтоб транзакция попала в ближайший блок.
Если юзер успел почесать репу, его первая транзакция уже разошлась по всей сети и вторую никто не примет.А что если вторая транзакция (говорим о DoubleSpend) идет с большей комиссией, чем первая? В этом случае она будет отвергнута?
Частный случай: первая транзакция была отправлена без комиссии, потом юзер почесал репу и все-таки решил не ждать N часов доброго майнера, а заплатить копейку чтоб транзакция попала в ближайший блок.
В этой теме обсуждается ситуация, когда мы одновременно отправляем транзакцию №1 в магазин, а транзакцию №2 в крупные пулы с надеждой на то, что магазин примет первую и отвергнет вторую, а пулы сделают наоборот. Магазин посчитает, что всё ок и выдаст товар, но выгодная для него транзакция №1 в блок не попадёт, а попадёт №2.
запишется только первая по времени поступления? не зависимо от комиссии видимо
а если на одном пуле №1 транзакция в мемо-пул а на другом №2 ? они ведь обмениваются меж собой данными - они не смогут разобраться какая из них "правильная"?? так чтобы на них 2-хх была только одна и таже транзакция
Если юзер успел почесать репу, его первая транзакция уже разошлась по всей сети и вторую никто не примет.
Вам не кажется, что тут есть проблема с деньгами, зависающими на потенциально неопределенное/бесконечное время? Допустим, я отправляю транзакцию с недостаточной комиссией для включения в блок (мы уже в той реальности, где транзакций настолько много, что майнеры включают в блок только самые выгодные транзакции). В результате - транзакция подвисает, сдачей с неё я тоже воспользоваться не могу. И получится, что я "повесив" платеж на рубль в результате блокирую весь свой счет на котором 100500 денег?
Не является ли в этом случае правильным алгоритмом для майнера в случае "конкурирующих" транзакций отвергать не вторую по порядку прихода, а менее выгодную? И да, в этом случае возможен "обман" магазинов, отпускающих товар до первого подтверждения.
Пытаюсь для себя понять как все работает. Так что простите если вопросы задаю глупые/некорректные
А что если вторая транзакция (говорим о DoubleSpend) идет с большей комиссией, чем первая? В этом случае она будет отвергнута?
Частный случай: первая транзакция была отправлена без комиссии, потом юзер почесал репу и все-таки решил не ждать N часов доброго майнера, а заплатить копейку чтоб транзакция попала в ближайший блок.
Если юзер успел почесать репу, его первая транзакция уже разошлась по всей сети и вторую никто не примет.А что если вторая транзакция (говорим о DoubleSpend) идет с большей комиссией, чем первая? В этом случае она будет отвергнута?
Частный случай: первая транзакция была отправлена без комиссии, потом юзер почесал репу и все-таки решил не ждать N часов доброго майнера, а заплатить копейку чтоб транзакция попала в ближайший блок.
В этой теме обсуждается ситуация, когда мы одновременно отправляем транзакцию №1 в магазин, а транзакцию №2 в крупные пулы с надеждой на то, что магазин примет первую и отвергнет вторую, а пулы сделают наоборот. Магазин посчитает, что всё ок и выдаст товар, но выгодная для него транзакция №1 в блок не попадёт, а попадёт №2.
Пытаюсь для себя понять как все работает. Так что простите если вопросы задаю глупые/некорректные
А что если вторая транзакция (говорим о DoubleSpend) идет с большей комиссией, чем первая? В этом случае она будет отвергнута?
Частный случай: первая транзакция была отправлена без комиссии, потом юзер почесал репу и все-таки решил не ждать N часов доброго майнера, а заплатить копейку чтоб транзакция попала в ближайший блок.
А что если вторая транзакция (говорим о DoubleSpend) идет с большей комиссией, чем первая? В этом случае она будет отвергнута?
Частный случай: первая транзакция была отправлена без комиссии, потом юзер почесал репу и все-таки решил не ждать N часов доброго майнера, а заплатить копейку чтоб транзакция попала в ближайший блок.
Конечно, если там клиент не из каменного века.
https://en.bitcoin.it/wiki/Protocol_specification#mempool
https://en.bitcoin.it/wiki/Protocol_specification#mempool
эээ
а разве я могу сделать запрос на пул чужой и узнать что у него в mempool ??
а разве я могу сделать запрос на пул чужой и узнать что у него в mempool ??
Если не собираешься проверять, что транзакция включена в пул всеми тремя, то просто список для connect указывать и все.
В противном случае придется править клиент. К примеру, можно добавить RPC вызов, который будет делать отправку mempool запроса на список пулов по очереди, и проверять наличие хэша транзакции в выдаче. Можно пойти дальше, и просто не показывать в выдаче listtransactions то, чего нет на всех пулах, тут все ограничено лишь фантазией.
Кстати, в случае реализации такого RPC вызова и списка пулов можно даже и не задумываться о специальных настройках клиента и прочем. Просто при получении делать mempool запросы к пулам для проверки, есть ли у пулов эта транзакция.
Короче, или просто (использовать пулы как фильтр, ничего менять не нужно) или посложнее (делать ручную проверку содержимого mempool) в зависимости от градуса паранойи.
В противном случае придется править клиент. К примеру, можно добавить RPC вызов, который будет делать отправку mempool запроса на список пулов по очереди, и проверять наличие хэша транзакции в выдаче. Можно пойти дальше, и просто не показывать в выдаче listtransactions то, чего нет на всех пулах, тут все ограничено лишь фантазией.
Кстати, в случае реализации такого RPC вызова и списка пулов можно даже и не задумываться о специальных настройках клиента и прочем. Просто при получении делать mempool запросы к пулам для проверки, есть ли у пулов эта транзакция.
Короче, или просто (использовать пулы как фильтр, ничего менять не нужно) или посложнее (делать ручную проверку содержимого mempool) в зависимости от градуса паранойи.
тоесть просто задать несколько коннектов к "доверенным пулам" и они сами отфильтруют все?
а кроме -connect что-то еще нужно задавать?
если все начнут так к пулам цепляться у них не хватит на всех maxconnections
может нужно что-то вроде listen? или коннект как раз и будет слушать только тот ИП?
и как узнать что все 3 пула эту транзакцию включили в свой mempool?
а кроме -connect что-то еще нужно задавать?
если все начнут так к пулам цепляться у них не хватит на всех maxconnections
может нужно что-то вроде listen? или коннект как раз и будет слушать только тот ИП?
и как узнать что все 3 пула эту транзакцию включили в свой mempool?
Это не проблема, потому что у пулов целые сетки из связанных между собой клиентов бывают запущены. Другое дело, что тут пул становится доверяемым узлом. То есть, отфильтровать-то гуано он конечно отфильтрует, но он и сам может сделать гуано. Но и тут есть вариант - несколько конкурирующих пулов вряд ли будут заниматься тем же самым гуаном, так что можно обрабатывать транзакцию если она пришла от двух-трех больших пулов.
В API команд нет, можно модифицировать клиент или просто указать в connect список найденных нод пулов. Входящие соединения, ircseed и dnsseed при этом необходимо отключить.
В API команд нет, можно модифицировать клиент или просто указать в connect список найденных нод пулов. Входящие соединения, ircseed и dnsseed при этом необходимо отключить.
Со стороны сервиса это уже сейчас решается привлечением посредников, в числе которых есть и пулы.
Кроме того, можно обойтись и без посредников - просканировать сеть, найти ноды пары крупных пулов и принимать транзакции, пришедшие только от них. Ноды в таком случае сыграют роль прокси-фильтра.
Кроме того, можно обойтись и без посредников - просканировать сеть, найти ноды пары крупных пулов и принимать транзакции, пришедшие только от них. Ноды в таком случае сыграют роль прокси-фильтра.
спасибо - я понял!
то есть пул не будет ретранслировать дальше "плохую" транзакцию
получается рипле не имеет никаких преимуществ перед биткоином
а если пул отвергнет соединение с моим кошельком?
и я не смогу проверить транзакции от него? может к нему и так уже зацепилось тьма нод
или есть команда в АПИ принимать только от них... или это надо на уровне своей сети фильтр какойто задавать?
-connect видимо не подойдет?
-bind=
Со стороны сервиса это уже сейчас решается привлечением посредников, в числе которых есть и пулы.
Кроме того, можно обойтись и без посредников - просканировать сеть, найти ноды пары крупных пулов и принимать транзакции, пришедшие только от них. Ноды в таком случае сыграют роль прокси-фильтра.
Кроме того, можно обойтись и без посредников - просканировать сеть, найти ноды пары крупных пулов и принимать транзакции, пришедшие только от них. Ноды в таком случае сыграют роль прокси-фильтра.
Сейчас референсный клиент отвергает дабл-спенд транзакции, не принимает в mempool.
На этом основана "надежность" транзакций без подтверждений. Что пулы, получив первую транзакцию, вторую уже не примут.
В действительности атаку провести можно совершенно без мощностей. Нужно лишь выяснить ip-адреса узлов крупных пулов и того сервиса, который нужно атаковать. Либо адреса ближайших к ним узлов.
Затем скормить им одновременно две разные транзакции. То есть тут эксплуатируются особенности топологии сети.
На этом основана "надежность" транзакций без подтверждений. Что пулы, получив первую транзакцию, вторую уже не примут.
В действительности атаку провести можно совершенно без мощностей. Нужно лишь выяснить ip-адреса узлов крупных пулов и того сервиса, который нужно атаковать. Либо адреса ближайших к ним узлов.
Затем скормить им одновременно две разные транзакции. То есть тут эксплуатируются особенности топологии сети.
я так понимаю что суть в том чтоЖ
1. на кошель магазина прислать транзакцию №1 - его ноду зацепить к своему кошельку чтобы к нему пришла транзакция быстро. магазин примет к оплате эту транзакцию. кошелек свой запускать на сервере физически рядом с магазином - скажем в европе или штатах.
2. из копии кшелька, размещенного физически в другом месте, послать 2ю транзакцию в которой эти монеты отсылаются на свой адрес напрямую на 3-4 пула которые имеют 70-80% мощности сети.
так может получиться ситуация что 1я транзакция будет первой в кошельке магазина а 2я транзакция будет первой в mempool пулов и она войдет в блок подтвержденной - можно так у буржуев укасть битки?
Всегда удивляло что никто никогда не придавал этому особого значения. Как SD начали даблспендить - чуть пошумели и успокоились.
Сейчас референсный клиент отвергает дабл-спенд транзакции, не принимает в mempool.
На этом основана "надежность" транзакций без подтверждений. Что пулы, получив первую транзакцию, вторую уже не примут.
В действительности атаку провести можно совершенно без мощностей. Нужно лишь выяснить ip-адреса узлов крупных пулов и того сервиса, который нужно атаковать. Либо адреса ближайших к ним узлов.
Затем скормить им одновременно две разные транзакции. То есть тут эксплуатируются особенности топологии сети.
На этом основана "надежность" транзакций без подтверждений. Что пулы, получив первую транзакцию, вторую уже не примут.
В действительности атаку провести можно совершенно без мощностей. Нужно лишь выяснить ip-адреса узлов крупных пулов и того сервиса, который нужно атаковать. Либо адреса ближайших к ним узлов.
Затем скормить им одновременно две разные транзакции. То есть тут эксплуатируются особенности топологии сети.
Jump to: