Pages:
Author

Topic: Мгновенные платежи (алгоритм реализации) - page 7. (Read 1924 times)

kzv
legendary
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange

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


Нет. Мгновенность оценивается по разности времени между двумя событиями: событие А - транзакция принята продавцом, событие Б - продавец отправил товар покупателю. Если продавцу нужно ждать подтверждения от сети, что это не даблспенд или даблспенд то это аналог именно скачивания, а не поиска пиров.


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


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

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

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

Нет?
Тогда действительно: по какому принципу банить? По ип адресу провайдера?
member
Activity: 280
Merit: 26
Хорошо. Пусть так. Только сразу возникает вопрос о "мгновенности" такой системы: сколько времени ждать ответа перед тем, как убедиться, что транзакция не даблспенд? 1 секунду, 30 секунд, 1 минуту? Когда пользователю уже точно можно отправлять пиццу за его коины?
"Мгновенность" можно оценить по скорости нахождения пиров в торренте (естественно, для случая, когда они есть).
Не скачивания - а именно нахождения пиров, обращаю внимание.
Quote
Ну допустим, что устанавливаем правило: если через 30 секунд никто не кричит о даблспенде, то транза валидная и больше ее отменять нельзя. Где гарантия тогда, что фродеру не удастся таким образом разделить сеть на несколько подсетей в каждой из которых будет свой вариант транзакции?
Фродеру надо не просто "разделить сеть" (что само по себе непросто), а разделить сеть так, чтобы N ближайших к нему хэшей-адресов оказались как-то "разделёнными".
Я вот лично как-то затрудняюсь даже представить, каким способом это можно сделать хотя бы теоретически.
Quote
Я так понямаю, у него юзеру назначается единственный номер кошелька типа как номер банковского счета. Поэтому банить можно по номеру этого счета. Как в банке.

Абсолютно нет, с чего бы это?
member
Activity: 280
Merit: 26
закономерный вопрос:
 - я могу создать две ноды, между ними гонять бесконечное количество даблспендов и спамить сеть бесконечным черным списком?
 - что будет, когда он будет оргомный? чем дольше будет сущестовать такая сеть, тем больше  будет черный список, тем медленнее будеть сеть?

Дык, "чёрным списком" из кого спамить-то? Списком из этих двух нод - так их и забанят один раз, на этом весь их "спам" закончится.
member
Activity: 280
Merit: 26
- Где гарантия что эта нода не отвалится, которая приняла мою транзакцию? и потом окажется, что моя транзакция так и повисла где-то?
 - если транзакции не синхронизируются сразу с другими нодам, я могу провести дабл спенд на другие ноды, допустим на счет биржы и перевести деньги в фиат, до того, как система успеет обновить данные на разных ее концах?
 - Хорошо, какой процент нод с реплицированным журналом моей транзакции гарантирует, что она свершилась и не может быть отката назад?


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

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

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

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

"Консенсус" - т.е., "согласие" - есть продукт непротивления сторон(с)
Т.е., весь "консенсус" - это согласие отправителя расстаться со своими "торрентокоинами", а получателя - принять их. Все остальные - просто свидетели, грубо говоря, следят за формальным соблюдением правил. Которые, опять же, могут быть какими угодными - ну, как захотели, так и написали.
Вообще, как я уже не раз говорил: у меня нет цели писать тут вайтпэйпер; принципа достаточно.
kzv
legendary
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange

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


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

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

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

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

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

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

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

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


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

меня больше волнует, как он будет банить ноды, если у него нет алгоритма консенсуса по сути
kzv
legendary
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange

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

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

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

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

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

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

- я не говорил про фейковую транзакцию, ее легко проверить подписью. я имею ввиду, что буду принимать транзакции и не отсылать дальше или делать вид, что это дабл спенд и банить счет?
- по тому же принчипу, что и банятся плохие ноды, я могу группой своих нод банить хорошие и остальным отсылать доказательства, например со своих счетов и своих подписей.
- что с блек листом и блек листом счетов?
- мемпул?
member
Activity: 280
Merit: 26
Не, ну очевидно же, что неспособные прочитать то, что 100500 раз написано и расписано - разумеется, ничего никуда сами не "отправят".

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

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

Участник neiros имеет 100 коинов, которые отправил одной транзакцией: kzv 35, lapitsky 30, fxpc 30 и DevilOper 5
kzv
legendary
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
member
Activity: 280
Merit: 26
В такой системе:
 - надо подтверждения 51% нод для проведения транзакции? (как будут синхронизироваться ноды, чтобы понять, что 51% уже наступил? это вектор нод или что?)
 - получается сеть должна при получении транзакции проверять каждый счет, не находится ли он в черном списке? (если очень сильно заспамить сеть таким списком, каждая транакция будет мучительно долго проходить?)
 - как защититься от подключения кучи фейковых нод, которые могут мешать работе сети? (простой пример, прикидываться хорошей нодой, но при получении транзакции изменять тело сообщения, соответсвенно, сеть будет отвергать ее после проверке подписи). Как система будет банить плохие ноды и по какому принципу?

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

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

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

Защита от фейковых нод точно такая же, как и в любой другой p2p сети: фейковая транзакция дальше первого же пира не уйдёт; фейковой ноде со своим фейком нужно будет коннектиться по очереди к другим оставшимся - и в конце концов, все её заблочат (достаточно быстро, на самом деле). По-крайней мере, в торрентах и мулях этот механизм работает достаточно эффективно.
member
Activity: 202
Merit: 27
Atom foundation
member
Activity: 280
Merit: 26
Ну вот А и Б обменялись номерами 12346, а остальные ноды как поймут, что у них 12346? Как будет реплецировать вся сеть эту транзакцию?

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

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

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

Ну вот А и Б обменялись номерами 12346, а остальные ноды как поймут, что у них 12346? Как будет реплецировать вся сеть эту транзакцию?
member
Activity: 280
Merit: 26
Таки да, про криптографию и вовсе никто не спорил на моей памяти. Сложна, нипанятна. Grin

Я вот давеча алгоритм Шора вкурить пытался, вот где сложна-нипанятна  Embarrassed
sr. member
Activity: 1316
Merit: 420
KTO EC/\U HUKTO?
Люди, здесь раздел "Кодеры".
А в этой теме 5 страниц спора.
Отправляйте говнокодеров читать "Вайтпейпер Биткоина" и "основы криптографии" и не разводите флуд.

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

Таки да, про криптографию и вовсе никто не спорил на моей памяти. Сложна, нипанятна. Grin
kzv
legendary
Activity: 1722
Merit: 1285
OpenTrade - Open Source Cryptocurrency Exchange
Люди, здесь раздел "Кодеры".
А в этой теме 5 страниц спора.
Отправляйте говнокодеров читать "Вайтпейпер Биткоина" и "основы криптографии" и не разводите флуд.

Ну справедливости ради нужно сказать, что спор крутится вокруг темы мгновенных транзакций,, а не просто как флуд.
jr. member
Activity: 76
Merit: 1
Люди, здесь раздел "Кодеры".
А в этой теме 5 страниц спора.
Отправляйте говнокодеров читать "Вайтпейпер Биткоина" и "основы криптографии" и не разводите флуд.
Pages:
Jump to: