Не стоит ли автоматически делать суммы в заявках более уникальными, для противодействия мошенникам?

[Helber]

Предлагаю компетентным людям (обменникам и, вероятно, «обменниковым» скриптоделам?) обсудить следующее мое дилетантское предложение.

Нет ли смысла «уникализировать» сумму  к отправке, сразу после того, как клиент создаст заявку в обменнике?
 

Предыстория. Немало случаев, когда обменник принимает крипту на один и тот же адрес от всех клиентов. В итоге этим пользуются мошенники — свежий пример. Назовем это разновидностью «треугольника» 

 

Либо при утечке данных с чьего-то компа, либо просто при слежке за адресом обменника (см.примечание под спойлером) мошенник подбирает момент для атаки. В ходе которой создает еще одну заявку по продаже крипты, чуть позже реального клиента, на ту же сумму, но со своими реквизитами. И, если повезет (по идее оператор должен такие заявки замечать и стопить, но все мы люди...)— мошенник получает ответную выплату по заявке (крипту по которой только что отправил клиент), и сваливает. А между клиентом и обменником начинаются неприятные разборки

P.S. Примечание. Этот вариант гораздо доступнее, но, поразмыслив, я его признаю уязвимым и рассчитанным только на поспешного и невнимательного оператора. Ведь при самой высокой скорости и автоматизации процесса липовая заявка на ту же сумму будет создана

позже

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

 

 

 

 

Возможны варианты, когда (возможно, это даже более частый вариант) клиент и мошенник — одно лицо.
Или когда нечестную третью сторону изображает обменник с кидальными наклонностями — у него в этом случае крайне выгодная позиция, всё происходящее идеально видно, а при контроле над своей БД даже что-то потом можно исправить задним числом.

 

 

Как пример. Обменник, из экономии, имеет на бирже всегда один и тот же адрес для получения BTC, на который и принимает все BTC от клиентов. (Вообще это нехорошо, конечно, но BTC не Tron  — транзакции до биржи стоят недешево и ходят медленно, и потому промежуточный личный кошелек с 100500 адресами не все обменники могут себе позволить).
Клиент приходит и создает заявку номер 43184 по продаже 0.05 BTC за сбер. Подтверждает.

 

На следующем шаге скрипт уменьшает сумму к оплате на небольшое случайное число сатошей и показывает клиенту, сколько и на какой адрес  отправить.
Или, может быть, меняет последние цифры суммы на последние цифры из номера заявки, например так — к оплате  0.04999184BTC, или 0.04999984. Мне этот вариант симпатичнее.

(Можно и чуть увеличивать сумму к отдаче, но клиентам это понравится меньше).
Сумма к получению остается прежней (ИМХО).

 

На странице оплаты ХОРОШО ЗАМЕТНЫМ шрифтом пишется, что сумма, которую должен выслать клиент, чуть ниже, чем он выбрал изначально, и что это защита от мошенников, просьба проявить понимание. 

В итоге, если 1) мошенник следит за приемным кошельком обменника и готов в подходящий момент нарисовать заявку-дубль (на ту же сумму, но без реальной оплаты), и 2) если клиент сам мошенник и норовит создать две заявки с двух аккаунтов, и 3) если чисто случайно совпало, что два разных честных клиента продают идентичные суммы крипты в одно время

— во всех случаях оператору будет легче понять, по какой заявке (если их видно две, обе на идентичные суммы) можно проводить оплату, так как именно по ней крипта поступила.

 

 

Я думал и над вариантом «уникализации» оплаты через прикрепление какого-то конкретного сообщения к транзакции. Видел такую опцию в blockchain.com, давно (см.мою первую тему на форуме), но видимо, из этого проку не будет, не говоря уж о крайней сложности для клиентов.

 

 

Может, кто предложит еще какие подходящие методы?

 

 

Теперь, не дожидаясь других, сам покритикую свою идею:

1)Это может быть слишком большое умножение сущностей, там, где

а) лучше справились бы хорошо обученные операторы, работа которых правильно налажена, в том числе, в плане избежания »треугольных» обманов типа описанного выше 

б) обменнику было бы посильно просто использовать уникальные для каждой заявки адреса.

2)Клиенты будут нередко ошибаться, особенно первое время после распространения описанной фишки.
В нашем примере — пенсионерка Глафира Петровна Арбуздыня создала заявку по продаже 0.05 биткоина за сбер, и столько же и отправила. Большую красную надпись про предосторожности и сумму к отправке 0.04999184 она не заметила. Заявка «застряла» или ее обработка замедлилась = Глафира Петровна недовольна.

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

3) Операторы могут начать ошибаться именно при такой новой системе (только я пока не придумал, как ? )

 

Кто еще хочет покритиковать, удлиняйте список.

Изменено 13 ноя 2020, 10:18 пользователем Helber

[trademaster]

На практике клиенты очень часто присылают суммы отличные от указанных в заявке. Чаще всего это связано с неучитыванием комиссии на вывод.

Если нет техническиой возможности принимать на разные адреса, не проще ли не принимать заявку на эту сумму вовсе? Магия с числами вряд ли сработает в виду не закладывания на комиссии пользователями. Причем комиссии разные с разных кошельков, в любом случае может так совпасть что 2 заявки будут на одну сумму.

Вообщем при использовании одного кошелька есть только один вариант - пока не обработаешь заявку от одного пользователя, не начинай обрабатывать следующего.

Можно, например, давать 10 минут на создание транзакции. Если нет транзакции в течение 10 минут в сети, то заявка автоотменяется и можно работать со следующим пользователем. Если транзакция бродкастнулась, то ждешь пока пройдет нужное количество подтверждений и в это время не принимаешь заявки.

Во всех остальных случаях накладки сумм будут возникать в любом случае.

Изменено 11 ноя 2020, 22:12 пользователем trademaster

[Helber]

3 минуты назад, trademaster сказал:

Если нет техническиой возможности принимать на разные адреса, не проще ли не принимать заявку на эту сумму вовсе?

Это как? Не понял, как вы сможете не принять заявку, когда по ней уже пришла «неправильная» сумма.

 

7 минут назад, trademaster сказал:

Причем комиссии разные с разных кошельков, в любом случае может так совпасть что 2 заявки будут на одну сумму.

То есть по одной заявке вы ждете 0.05013556, приходит точно столько, и по другой ждете 0.05043557, но приходит ровно 0.05013556? 
Но какова вероятность того, что комиссия во втором случае окажется ровно 30001 сатош, а не 28736 или 30581? Имхо, это крайне редкое совпадение.

 

11 минут назад, trademaster сказал:

Вообщем при использовании одного кошелька есть только один вариант - пока не обработаешь заявку от одного пользователя, не начинай обрабатывать следующего.

Дешево и сердито! Как вариант)

Только если вы увидите две заявки по 0.05 BTC и одно реальное поступление, вы вообще не сможете обработать ни одну из них до получения дополнительной информации.

 

И даже без этого, темп работы будет ниже, чем у конкурентов. 

16 минут назад, trademaster сказал:

Можно, например, давать 10 минут на создание транзакции. Если нет транзакции в течение 10 минут в сети, то заявка автоотменяется и можно работать со следующим пользователем. Если транзакция бродкастнулась, то ждешь пока пройдет нужное количество подтверждений и в это время не принимаешь заявки.

Опять-таки настрой на весьма неспешный темп работы. Может быть, это не всем подходит. Я не знаю.

[trademaster]

2 minutes ago, Helber said:

Это как? Не понял, как вы сможете не принять заявку, когда по ней уже пришла «неправильная» сумма.

Я имел в виду, что если кто-то создал заявку, то пока с ней не разберетесь, система не дает создать заявку никому больше. И давать 10 минут на создание транзакции в сеть для заявки, как один из вариантов.

 

9 minutes ago, Helber said:

То есть по одной заявке вы ждете 0.05013556, приходит точно столько, и по другой ждете 0.05043557, но приходит ровно 0.05013556? 

Да, вы правильно меня поняли.

 

5 minutes ago, Helber said:

Имхо, это крайне редкое совпадение.

Я с вами согласен, редкое, но возможное.

 

11 minutes ago, Helber said:

Только если вы увидите две заявки по 0.05 BTC

Я имел в виду, что не может быть 2 заявки необрпаботанных. Есть только одна, пока с ней обменник не закончит не давать создавать новую заявку и просить подождать 10 минут.

 

12 minutes ago, Helber said:

И даже без этого, темп работы будет ниже, чем у конкурентов. 

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

[kursexpert]

В целом идея очень хорошая и я даже время от времени о ней думал). НО! Есть ряд минусов и совсем не тех, которые вы описали:

1. Сами клиенты часто негативно относятся если сумма отличается от заявленной. Т.е. например человек ввел 0,2 к оплате и если сумма будет 0,20001, то это вызовет негативную реакцию. 

2. Технический момент. Во многих скриптах предварительный расчет на обменниках я так понимаю делается на java или подтягивается и потом это нужно пересчитать в php. Это достаточно тонкий момент. 

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

Изменено 12 ноя 2020, 13:18 пользователем kursexpert

[Helber]

@kursexpert , спасибо за ответ.

18 минут назад, kursexpert сказал:

Т.е. например человек ввел 0,2 к оплате и если сумма будет 0,20001, то это вызовет негативную реакцию. 

И на ваш взгляд, если предложить отправить 0,19999, реакция будет опять же негативной? Можно изображать не только как меру защиты от мошенников, но и/или как скидку. Этакий маркетинговый ход. Будет ли прок?

 

20 минут назад, kursexpert сказал:

Нужно учитывать, что есть очень простая лазейка обойти это все. Мошеннику достаточно отправить ровную сумму и сказать, что ошибся

То есть это вы описываете случай, когда клиент-жулик играет за двоих, и реально отправляет с первого акка намеренно округленные 0.05, и со второго делает фиктивную заявку на 0.04999184? 
Ну, как минимум, «неправильная сумма», полученная обменником, позволит ему сразу заметить, «что-то не так», и затормозить оплату обеих заявок. Затем уже можно более спокойно и не торопясь поразбираться с конкурирующими заявками.

[kursexpert]

38 минут назад, Helber сказал:

То есть это вы описываете случай, когда клиент-жулик играет за двоих, и реально отправляет с первого акка намеренно округленные 0.05, и со второго делает фиктивную заявку на 0.04999184? 
Ну, как минимум, «неправильная сумма», полученная обменником, позволит ему сразу заметить, «что-то не так», и затормозить оплату обеих заявок. Затем уже можно более спокойно и не торопясь поразбираться с конкурирующими заявками.

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

Изменено 12 ноя 2020, 14:22 пользователем kursexpert

[Helber]

1 час назад, kursexpert сказал:

Альфабит сам признал, что была ошибка оператора изначально, т.е. блок я так понимаю там был.

Я не совсем понял эту мысль - т.е. там была предусмотрена система блокировок при идентичных заявках, и она в этот раз не сработала только из-за человеческого фактора? Так надо вас  понять?

 

Просто если реальное поступление и номер заявки должны между собой коррелировать, и оператор это знает, это влияние «человеческого фактора» может уменьшить.

 

Кстати, сейчас подумал — можно было бы на анализаторе как-то помечать обменники, которые по данному направлению принимают всегда на разные адреса. Чтобы отличать тех, кто с точки зрения клиента имеет лишний слой защиты от «треугольников»

 

Сейчас посмотрел свои отправки USDT TRC-20 в кошельке, разным обменникам — по крайней мере один из них принимает USDT на один и тот же адрес. Но ведь троновый USDT и летает почти мгновенно и пересылается довольно дешево. Какая вообще экономия в том, чтобы принимать его на свой биржевой адрес. Или кошелек личный, и тут просто технические заморочки относительно изменения адресов приема?

[kursexpert]

48 минут назад, Helber сказал:

Я не совсем понял эту мысль - т.е. там была предусмотрена система блокировок при идентичных заявках, и она в этот раз не сработала только из-за человеческого фактора?

Я понял, что именно так все было.