Мгновенные платежи (алгоритм реализации)

[neiros]

Нет, ну если не умеешь в последовательный счёт и к 12345 прибавить 1 - то это уже не "доверять", а веровать; впрочем, можно и секту свидетелей последовательного счёта замутить, по аналогии с карго-культом свидетелей лохчейна.

... за убеждения ... https://www.youtube.com/watch?v=EHX7NZS8zAI


Сектант секты свидетелей [кончины секты свидетелей лохчейна] всё ещё никак не угомонится?

[Blockchain.Artificial]

Люди, здесь раздел "Кодеры".
А в этой теме 5 страниц спора.
Отправляйте говнокодеров читать "Вайтпейпер Биткоина" и "основы криптографии" и не разводите флуд.

[kzv]

Люди, здесь раздел "Кодеры".
А в этой теме 5 страниц спора.
Отправляйте говнокодеров читать "Вайтпейпер Биткоина" и "основы криптографии" и не разводите флуд.

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

[fxpc]

Люди, здесь раздел "Кодеры".
А в этой теме 5 страниц спора.
Отправляйте говнокодеров читать "Вайтпейпер Биткоина" и "основы криптографии" и не разводите флуд.

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

Таки да, про криптографию и вовсе никто не спорил на моей памяти. Сложна, нипанятна.

[DevilOper]

Таки да, про криптографию и вовсе никто не спорил на моей памяти. Сложна, нипанятна.

Я вот давеча алгоритм Шора вкурить пытался, вот где сложна-нипанятна 

[lapitsky]

Нет, ну если не умеешь в последовательный счёт и к 12345 прибавить 1 - то это уже не "доверять", а веровать; впрочем, можно и секту свидетелей последовательного счёта замутить, по аналогии с карго-культом свидетелей лохчейна.

Ну вот А и Б обменялись номерами 12346, а остальные ноды как поймут, что у них 12346? Как будет реплецировать вся сеть эту транзакцию?

[DevilOper]

Ну вот А и Б обменялись номерами 12346, а остальные ноды как поймут, что у них 12346? Как будет реплецировать вся сеть эту транзакцию?

Дак я ж писал уже в другой теме по ссылкам, что я давал.
Ну Ок, похоже, надо снова.

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

Пришла транзакция от А к Б ноде Х - она проверяет подпись А и номер последней транзакции от А который в журнале.
Если +1 - то всё в порядке, инкрементируем, пересчитываем баланс (на самом деле, ставим в "ожидание" и ждём подтверждения от получателя, ну это детали).
Если +2 и больше - ставим в очередь и ждём какое-то время +1. (После таймаута - запрос на синхронизацию обычным мажоритарным "голосованием", то же самое для новой ноды).
Если номер какой-то старый - транзакция просто выкидывается (можно ещё какой-нибудь алерт рассылать другим участнегам, это уже детали).
Если номер тот же, что и у последней транзакции - стОит приглядеться повнимательней, либо это просто одна и та же "заблудилась" - либо попытка фрода, тогда отправителю бан (на этой ноде) и (опционно) сообщение остальным.
Как-то так вкратце.

[lapitsky]

Ну вот А и Б обменялись номерами 12346, а остальные ноды как поймут, что у них 12346? Как будет реплецировать вся сеть эту транзакцию?

Дак я ж писал уже в другой теме по ссылкам, что я давал.
Ну Ок, похоже, надо снова.

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

Пришла транзакция от А к Б ноде Х - она проверяет подпись А и номер последней транзакции от А который в журнале.
Если +1 - то всё в порядке, инкрементируем, пересчитываем баланс (на самом деле, ставим в "ожидание" и ждём подтверждения от получателя, ну это детали).
Если +2 и больше - ставим в очередь и ждём какое-то время +1. (После таймаута - запрос на синхронизацию обычным мажоритарным "голосованием", то же самое для новой ноды).
Если номер какой-то старый - транзакция просто выкидывается (можно ещё какой-нибудь алерт рассылать другим участнегам, это уже детали).
Если номер тот же, что и у последней транзакции - стОит приглядеться повнимательней, либо это просто одна и та же "заблудилась" - либо попытка фрода, тогда отправителю бан (на этой ноде) и (опционно) сообщение остальным.
Как-то так вкратце.

Вроде логично 

В такой системе:
 - надо подтверждения 51% нод для проведения транзакции? (как будут синхронизироваться ноды, чтобы понять, что 51% уже наступил? это вектор нод или что?)
 - получается сеть должна при получении транзакции проверять каждый счет, не находится ли он в черном списке? (если очень сильно заспамить сеть таким списком, каждая транакция будет мучительно долго проходить?)
 - как защититься от подключения кучи фейковых нод, которые могут мешать работе сети? (простой пример, прикидываться хорошей нодой, но при получении транзакции изменять тело сообщения, соответсвенно, сеть будет отвергать ее после проверке подписи). Как система будет банить плохие ноды и по какому принципу?

[DevilOper]

В такой системе:
 - надо подтверждения 51% нод для проведения транзакции? (как будут синхронизироваться ноды, чтобы понять, что 51% уже наступил? это вектор нод или что?)
 - получается сеть должна при получении транзакции проверять каждый счет, не находится ли он в черном списке? (если очень сильно заспамить сеть таким списком, каждая транакция будет мучительно долго проходить?)
 - как защититься от подключения кучи фейковых нод, которые могут мешать работе сети? (простой пример, прикидываться хорошей нодой, но при получении транзакции изменять тело сообщения, соответсвенно, сеть будет отвергать ее после проверке подписи). Как система будет банить плохие ноды и по какому принципу?

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

Подтверждением транзакции, как сказал выше, является подтверждение её получения получателем.

Ноды просто хранят "журнал". Причём, даже не обязательно всем всё хранить. Каждый счёт проверять так же не нужно - только отправителя (т.е., даже махровый фейкомёт, в принципе, может получать транзакции, на целостность "сети" это никак не повлияет - правда, с подтверждениями полученя могут возникнуть проблемы).
Транзакции "публикуются" примерно так же, как работает DHT: помимо получателя, транзакция отправляется 3-м, (5-и, 35-и - не важно) "ближайшим" по хэшу (т.е., "адресу") отправителя и получателя нодам (те, в свою очередь, при наличии в их таблице более ближайших - пересылают им. таким образом, даже если транзакцию просто "кинуть наугад" - она всё равно доберётся, куда надо).
Получивший транзакцию прежде, чем подтвердить её, запрашивает информацию у тех же нод, затем точно так же им же раздаёт подтверждение.

Защита от фейковых нод точно такая же, как и в любой другой p2p сети: фейковая транзакция дальше первого же пира не уйдёт; фейковой ноде со своим фейком нужно будет коннектиться по очереди к другим оставшимся - и в конце концов, все её заблочат (достаточно быстро, на самом деле). По-крайней мере, в торрентах и мулях этот механизм работает достаточно эффективно.

[kzv]

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

Подтверждением транзакции, как сказал выше, является подтверждение её получения получателем.

Ноды просто хранят "журнал". Причём, даже не обязательно всем всё хранить. Каждый счёт проверять так же не нужно - только отправителя (т.е., даже махровый фейкомёт, в принципе, может получать транзакции, на целостность "сети" это никак не повлияет - правда, с подтверждениями полученя могут возникнуть проблемы).
Транзакции "публикуются" примерно так же, как работает DHT: помимо получателя, транзакция отправляется 3-м, (5-и, 35-и - не важно) "ближайшим" по хэшу (т.е., "адресу") отправителя и получателя нодам (те, в свою очередь, при наличии в их таблице более ближайших - пересылают им. таким образом, даже если транзакцию просто "кинуть наугад" - она всё равно доберётся, куда надо).
Получивший транзакцию прежде, чем подтвердить её, запрашивает информацию у тех же нод, затем точно так же им же раздаёт подтверждение.

Защита от фейковых нод точно такая же, как и в любой другой p2p сети: фейковая транзакция дальше первого же пира не уйдёт; фейковой ноде со своим фейком нужно будет коннектиться по очереди к другим оставшимся - и в конце концов, все её заблочат (достаточно быстро, на самом деле). По-крайней мере, в торрентах и мулях этот механизм работает достаточно эффективно.

Два варианта событий.

Вариант первый

DevilOper: хранит в своем журнале транзакции для трех участников и для себя естественно
1. Участник kzv: последняя транза имеет номер 100500 итоговый баланс счета 100 коинов
2. Участник lapitsky: последняя транза имеет номер 100 итоговый баланс счета 1000 коинов
3. Участник fxpc: последняя транза имеет номер 500 итоговый баланс счета 10000 коинов
4. Участник DevilOper: последняя транза имеет номер 1 итоговый баланс счета 100000 коинов

kzv: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**

lapitsky: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**

fxpc: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**


kzv отправил новую транзакцию с номером 100501 к fxpc: "отдаю 100 коинов участнику DevilOper"
kzv отправил новую транзакцию с номером 100501 к lapitsky: "отдаю 100 коинов участнику fxpc"

Что дальше?
Обе транзы от kzv - с его правильной подписью и с правильным номером. Значит они обе валидны и должны быть записаны в журнал?

Ну попробую догадаться: fxpc и lapitsky когда получат новую транзакцию должны разослать о них алерт всей сети и дождаться ответов типа "обнаружена попытка даблспенда"?
Дальше fxpc и lapitsky банят kzv за попытку даблспенда правильно?
Ну здорово. Алгоритм консенсуса отличный!

Теперь вариант второй

DevilOper: хранит в своем журнале транзакции для трех участников и для себя естественно
1. Участник kzv: последняя транза имеет номер 100500 итоговый баланс счета 100 коинов
2. Участник lapitsky: последняя транза имеет номер 100 итоговый баланс счета 1000 коинов
3. Участник fxpc: последняя транза имеет номер 500 итоговый баланс счета 10000 коинов
4. Участник DevilOper: последняя транза имеет номер 1 итоговый баланс счета 100000 коинов

kzv: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**

lapitsky: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**

fxpc: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**

kzv отправил новую транзакцию с номером 100501 к fxpc: "отдаю 100 коинов участнику lapitsky"
fxpc: отправил алерт с содержимым транзакции
DevilOper: (просто из-за своей вредности) посылает ответ "обнаружена попытка даблспенда"

Что дальше?
Согласно алгоритму из первого варианта, fxpc забанит kzv?

[neiros]

Небольшой довесок к посту kzv.

Участник neiros имеет 100 коинов, которые отправил одной транзакцией: kzv 35, lapitsky 30, fxpc 30 и DevilOper 5

[DevilOper]

Не, ну очевидно же, что неспособные прочитать то, что 100500 раз написано и расписано - разумеется, ничего никуда сами не "отправят".

А тот софт што им дале в зубы более умные дядьке - он работает правельно по-умолчанию без всяких сомнений, патамушта они золотые а кагжы исчо он можыд роботать. Инфа 146%, великий Паниковский сотошыно комодо гoрoнтируед!

[lapitsky]

Ноды просто хранят "журнал". Причём, даже не обязательно всем всё хранить. Каждый счёт проверять так же не нужно - только отправителя (т.е., даже махровый фейкомёт, в принципе, может получать транзакции, на целостность "сети" это никак не повлияет - правда, с подтверждениями полученя могут возникнуть проблемы).

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

Защита от фейковых нод точно такая же, как и в любой другой p2p сети: фейковая транзакция дальше первого же пира не уйдёт; фейковой ноде со своим фейком нужно будет коннектиться по очереди к другим оставшимся - и в конце концов, все её заблочат (достаточно быстро, на самом деле). По-крайней мере, в торрентах и мулях этот механизм работает достаточно эффективно.

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

[lapitsky]

Вариант первый

DevilOper: хранит в своем журнале транзакции для трех участников и для себя естественно
1. Участник kzv: последняя транза имеет номер 100500 итоговый баланс счета 100 коинов
2. Участник lapitsky: последняя транза имеет номер 100 итоговый баланс счета 1000 коинов
3. Участник fxpc: последняя транза имеет номер 500 итоговый баланс счета 10000 коинов
4. Участник DevilOper: последняя транза имеет номер 1 итоговый баланс счета 100000 коинов

kzv: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**

lapitsky: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**

fxpc: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**


kzv отправил новую транзакцию с номером 100501 к fxpc: "отдаю 100 коинов участнику DevilOper"
kzv отправил новую транзакцию с номером 100501 к lapitsky: "отдаю 100 коинов участнику fxpc"

Что дальше?
Обе транзы от kzv - с его правильной подписью и с правильным номером. Значит они обе валидны и должны быть записаны в журнал?

Ну попробую догадаться: fxpc и lapitsky когда получат новую транзакцию должны разослать о них алерт всей сети и дождаться ответов типа "обнаружена попытка даблспенда"?
Дальше fxpc и lapitsky банят kzv за попытку даблспенда правильно?
Ну здорово. Алгоритм консенсуса отличный!

Знаешь, я уже вроде глубоко изучил его доморощенный торрент, твоя задачка у него будет решаться так:
- если нода получает траназкцию с номером +1, тогда она проверяет ее и пишет в журнал
- если +2, просто ждет +1
- если транзакция получила две транзакции с одинаковым номером (дабл спенд или кошелек/скрипт случайно не сделал +1, тогда обе транзакции отменяются у этой ноды и сообщения остальным)

из этого вопросы:
- как будет выглядить роллбек, если нода получает транзакцию +2, когда первая еще не обработана и денег на счету не хватает? как будет выглдяить тогда ролбек у других нод? как журнал синхронизиурется?
- если есть +2, но никак не прилетает +1, что будет?

Теперь вариант второй

DevilOper: хранит в своем журнале транзакции для трех участников и для себя естественно
1. Участник kzv: последняя транза имеет номер 100500 итоговый баланс счета 100 коинов
2. Участник lapitsky: последняя транза имеет номер 100 итоговый баланс счета 1000 коинов
3. Участник fxpc: последняя транза имеет номер 500 итоговый баланс счета 10000 коинов
4. Участник DevilOper: последняя транза имеет номер 1 итоговый баланс счета 100000 коинов

kzv: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**

lapitsky: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**

fxpc: хранит в своем журнале транзакции для трех участников и для себя естественно
**все в точности как у DevilOper**

kzv отправил новую транзакцию с номером 100501 к fxpc: "отдаю 100 коинов участнику lapitsky"
fxpc: отправил алерт с содержимым транзакции
DevilOper: (просто из-за своей вредности) посылает ответ "обнаружена попытка даблспенда"

Что дальше?
Согласно алгоритму из первого варианта, fxpc забанит kzv?

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

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

[kzv]

- если транзакция получила две транзакции с одинаковым номером (дабл спенд или кошелек/скрипт случайно не сделал +1, тогда обе транзакции отменяются у этой ноды и сообщения остальным)

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

Если с первым случаем все понятно: забанить фродера и не париться, то как решать вопрос о бане во втором случае - вопрос открытый.

[lapitsky]

- если транзакция получила две транзакции с одинаковым номером (дабл спенд или кошелек/скрипт случайно не сделал +1, тогда обе транзакции отменяются у этой ноды и сообщения остальным)

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

Если с первым случаем все понятно: забанить фродера и не париться, то как решать вопрос о бане во втором случае - вопрос открытый.

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

меня больше волнует, как он будет банить ноды, если у него нет алгоритма консенсуса по сути

[kzv]

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

Хорошо. Пусть так. Только сразу возникает вопрос о "мгновенности" такой системы: сколько времени ждать ответа перед тем, как убедиться, что транзакция не даблспенд? 1 секунду, 30 секунд, 1 минуту? Когда пользователю уже точно можно отправлять пиццу за его коины?

Ну допустим, что устанавливаем правило: если через 30 секунд никто не кричит о даблспенде, то транза валидная и больше ее отменять нельзя. Где гарантия тогда, что фродеру не удастся таким образом разделить сеть на несколько подсетей в каждой из которых будет свой вариант транзакции?

Понятно, что чем дольше ждем подтверждения, тем меньше вероятность сплита, но что делать если сплит все таки произошел?

меня больше волнует, как он будет банить ноды, если у него нет алгоритма консенсуса по сути

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

[DevilOper]

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

Какой-то QoS протокол, конечно, должен быть. Чтобы "онлайновость" нод как-то знать, ну и записи с оставшихся реплицировать, если какая-то уходит в оффлайн и доступных копий становится меньше.
Но это, в общем-то, не имеет отношения к самому, если можно так выразиться, "алгоритму транзакций".
А если речь о получателе - так он прислать подтверждение получения должен. Если не прислал - значит, не получал, транзакция откатывается.
По минимуму хватит 3-х копий журнала, ну а так-то - чем больше, тем лучше.

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

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

меня больше волнует, как он будет банить ноды, если у него нет алгоритма консенсуса по сути

"Консенсус" - т.е., "согласие" - есть продукт непротивления сторон(с)
Т.е., весь "консенсус" - это согласие отправителя расстаться со своими "торрентокоинами", а получателя - принять их. Все остальные - просто свидетели, грубо говоря, следят за формальным соблюдением правил. Которые, опять же, могут быть какими угодными - ну, как захотели, так и написали.
Вообще, как я уже не раз говорил: у меня нет цели писать тут вайтпэйпер; принципа достаточно.

[DevilOper]

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

Дык, "чёрным списком" из кого спамить-то? Списком из этих двух нод - так их и забанят один раз, на этом весь их "спам" закончится.

[DevilOper]

Хорошо. Пусть так. Только сразу возникает вопрос о "мгновенности" такой системы: сколько времени ждать ответа перед тем, как убедиться, что транзакция не даблспенд? 1 секунду, 30 секунд, 1 минуту? Когда пользователю уже точно можно отправлять пиццу за его коины?

"Мгновенность" можно оценить по скорости нахождения пиров в торренте (естественно, для случая, когда они есть).
Не скачивания - а именно нахождения пиров, обращаю внимание.

Ну допустим, что устанавливаем правило: если через 30 секунд никто не кричит о даблспенде, то транза валидная и больше ее отменять нельзя. Где гарантия тогда, что фродеру не удастся таким образом разделить сеть на несколько подсетей в каждой из которых будет свой вариант транзакции?

Фродеру надо не просто "разделить сеть" (что само по себе непросто), а разделить сеть так, чтобы N ближайших к нему хэшей-адресов оказались как-то "разделёнными".
Я вот лично как-то затрудняюсь даже представить, каким способом это можно сделать хотя бы теоретически.

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

Абсолютно нет, с чего бы это?