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

[kzv]

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

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

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

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

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

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

Нет?
Тогда действительно: по какому принципу банить? По ип адресу провайдера?

[lapitsky]

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

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

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

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

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

а если получатель офлайн, как он получит денег? я что-то не понял, где у тебя хранятся деньги и данные о кошельках?

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

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

Вообще, как я уже не раз говорил: у меня нет цели писать тут вайтпэйпер; принципа достаточно.

ну у тебя здравая идея, просто надо глубоко в ней разобраться и понять, действительно ли эта система работает.

[DevilOper]

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

Ничё не понял, кто на ком стоял какому третьему отправил, куда отвалился?
Если хоть одна нода получила подтверждение о приёме с подписью - всё, транзакцию можно считать завешённой, ноды его передадут другим дальше.
Чтобы оно не ушло дальше в сеть - надо очень сильное колдунство, чтобы получившая/ие его нода/ы дальше тоже не передали - ну, это теоретически можно организовать, но будет равносильно тому, что получатель его не отправлял. Т.е., "выхлоп" от подобных усилий нулевой.
Таймаут - да хз, каким. Не 10 минут всяко - секунды.

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

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

а если получатель офлайн, как он получит денег?

Можно, наверное, при желании даже, например, "отложенный платёж" организовать - не думал ещё над этим, но не вижу препятствий.
Хотя, опять же, в чём препятствие получателю на 10 сек в сеть выйти?

я что-то не понял, где у тебя хранятся деньги и данные о кошельках?

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

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

У меня нет "консенсуса" в лохчейновом его понимании, но во-первых, с какого перепугу решили, что это единственный возможный вариант "консенсуса", а во-вторых, такой футбол консенсус нам не нужен!(с)
"Спама", "проверок" и "тестов" в моей системе на 100500 порядков меньше, чем в лохчейновой - ну, если проверять всё, как положено, от merkle root.

надо ... понять, действительно ли эта система работает.

Ну так в LN же как-то работает. Хотя и в ублюдочно-пасквильном виде.

[lapitsky]

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

Если хоть одна нода получила подтверждение о приёме с подписью - всё, транзакцию можно считать завешённой, ноды его передадут другим дальше.
Таймаут - да хз, каким. Не 10 минут всяко - секунды.

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

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

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

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

Что из этого?

а если получатель офлайн, как он получит денег?

Можно, наверное, при желании даже, например, "отложенный платёж" организовать - не думал ещё над этим, но не вижу препятствий.
Хотя, опять же, в чём препятствие получателю на 10 сек в сеть выйти?

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

Хотя, опять же, в чём препятствие получателю на 10 сек в сеть выйти?

Это бред. Как ты будешь создавать на этой системе смартконтракты с выходом в сеть на 10 сек? Крипта без смартконтрактов, это смерть.

"Спама", "проверок" и "тестов" в моей системе на 100500 порядков меньше, чем в лохчейновой - ну, если проверять всё, как положено, от merkle root.

Я не про проверки всех транзакций от начала, я о проверках свежих данные в нодах. Как нода будет знать, что у нее свежие данные по кошельку?

Ну так в LN же как-то работает. Хотя и в ублюдочно-пасквильном виде.

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

[#Cryptoman]

- нода сообщает другим нодам, что нода Х плохая и ее надо банить

А если неправильная нода быстрее будет отсылать информацию о "неправильных" нодах, с целью развалить сеть?

[lapitsky]

- нода сообщает другим нодам, что нода Х плохая и ее надо банить

А если неправильная нода быстрее будет отсылать информацию о "неправильных" нодах, с целью развалить сеть?

должна быть подпись под неправильной информацией, это легко решается.

[Vtools]

- нода сообщает другим нодам, что нода Х плохая и ее надо банить

А если неправильная нода быстрее будет отсылать информацию о "неправильных" нодах, с целью развалить сеть?

должна быть подпись под неправильной информацией, это легко решается.

А как защититься от правильной "неправильной информации", но отправленной в качестве спама в огромных количествах?
Например, у зловреда одна есть нода, которая генерит неправильную информацию, а другая радостно ее идентифицирует и отправляет как "защиту" в сеть, но на самом деле выполняет ДДОС атаку сети.

[kzv]

- нода сообщает другим нодам, что нода Х плохая и ее надо банить

А если неправильная нода быстрее будет отсылать информацию о "неправильных" нодах, с целью развалить сеть?

должна быть подпись под неправильной информацией, это легко решается.

А как защититься от правильной "неправильной информации", но отправленной в качестве спама в огромных количествах?
Например, у зловреда одна есть нода, которая генерит неправильную информацию, а другая радостно ее идентифицирует и отправляет как "защиту" в сеть, но на самом деле выполняет ДДОС атаку сети.

Забанить обе ноды. Не спрашивайте по какому принципу только.

[Vtools]

- нода сообщает другим нодам, что нода Х плохая и ее надо банить

А если неправильная нода быстрее будет отсылать информацию о "неправильных" нодах, с целью развалить сеть?

должна быть подпись под неправильной информацией, это легко решается.

А как защититься от правильной "неправильной информации", но отправленной в качестве спама в огромных количествах?
Например, у зловреда одна есть нода, которая генерит неправильную информацию, а другая радостно ее идентифицирует и отправляет как "защиту" в сеть, но на самом деле выполняет ДДОС атаку сети.

Забанить обе ноды. Не спрашивайте по какому принципу только.

Почему две? Или в вашем блокчейне распространять информацию о неправильной информации запрещается?

[kzv]

Почему две? Или в вашем блокчейне распространять информацию о неправильной информации запрещается?

Блокчейн не мой, но думаю да: неправильную информацию распространять запрещается.

[lapitsky]

А как защититься от правильной "неправильной информации", но отправленной в качестве спама в огромных количествах?
Например, у зловреда одна есть нода, которая генерит неправильную информацию, а другая радостно ее идентифицирует и отправляет как "защиту" в сеть, но на самом деле выполняет ДДОС атаку сети.

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

[TheMadman1992]

А как защититься от правильной "неправильной информации", но отправленной в качестве спама в огромных количествах?
Например, у зловреда одна есть нода, которая генерит неправильную информацию, а другая радостно ее идентифицирует и отправляет как "защиту" в сеть, но на самом деле выполняет ДДОС атаку сети.

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

Как-то недоработан этот вопрос... Должны же быть какие-то гарантии, что хорошие ноды не будут банить. Как вообще у них отфильтровка будет идти? непонятно..

[DevilOper]

Ок, я понял, тут - как в армии: офицерам надо повторять медленно и два раза, а прапорщикам - четыре.

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

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

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

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

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

Что из этого?

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

Да что угодно из этого, хоть ничего вообще.

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

Суть в том, что пока большинство нод придерживается единого алгоритма - меньшинство может сделать что-либо только в ущерб себе.
Как только меньшинство становится большинством с едиными правилами - ну, остальным придётся подстраиваться под новые правила; и кстати, в этом вашем лохчейне - всё точно так же.
Обращаю внимание на выделенное. Ибо, 100500 нод каждая со своими правилами - это не большинство, это всё ещё 100500 сексуальных меньшинств.

Получатель всегда в офлайн. Так как обычный владелец кошелька только придьявлять свою подпись для проведения транзакции.
В твоем случае владелец кошелька = сидер. Что если номер кошелька другой, что если у владельца их десятки. Что если у него холодный кошелек.
...
Это бред. Как ты будешь создавать на этой системе смартконтракты с выходом в сеть на 10 сек? Крипта без смартконтрактов, это смерть.

Я уже говорил: высуньте мозги из этого вашго лохчейна, пока они там окончательно не усохли и заплесневели.
Какие в Ж "смартконтракты", мне "смартконтракт" полы помоет или пиццу запечёт, например? Ну, и хер смысла тогда в этой словесной мастурбации.

Я не про проверки всех транзакций от начала, я о проверках свежих данные в нодах. Как нода будет знать, что у нее свежие данные по кошельку?

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

Как я знаю, там атомарные операции

Эрекция... эякуляция...(с)
Я вот вижу склонность к жонглированию терминами без понимания их смысла. Что в данном контексте означает "атомарные операции"? Как вообще можно сделать "атомарную операцию" в сети, базирующейся на TCP протоколе

[DevilOper]

А как защититься от правильной "неправильной информации", но отправленной в качестве спама в огромных количествах?
Например, у зловреда одна есть нода, которая генерит неправильную информацию, а другая радостно ее идентифицирует и отправляет как "защиту" в сеть, но на самом деле выполняет ДДОС атаку сети.

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

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

[lapitsky]

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

Прикинь, да) В битке то алгоритм консенсуа как раз решает эту проблему помимо других. если бы ты разобрался, то понял как) Так что ответ не защитан.
tcp уже сам по себе является тем протоколом, который решил эту проблему, в отличии от udp, но он не решает проблему репликации, журнала, консенсуса, как хочешь назови.

Суть в том, что пока большинство нод придерживается единого алгоритма - меньшинство может сделать что-либо только в ущерб себе.

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

Я уже говорил: высуньте мозги из этого вашго лохчейна, пока они там окончательно не усохли и заплесневели.
Какие в Ж "смартконтракты", мне "смартконтракт" полы помоет или пиццу запечёт, например? Ну, и хер смысла тогда в этой словесной мастурбации.

Это не блокчейн придумал и это слово появилось очень давно, и просто является правилами для проведения сделок.
Первые идеи умных контрактов были предложены в 1994 году Ником Сабо

По какому кошельку? По своему - так они у неё по умолчанию свежие. Странно было бы свой кошелёк в несвежем состоянии хранить.

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

Я вот вижу склонность к жонглированию терминами без понимания их смысла. Что в данном контексте означает "атомарные операции"? Как вообще можно сделать "атомарную операцию" в сети, базирующейся на TCP протоколе

Вы почитайте и узнаете, я удосужился и почитал, есть много статей и видео по теме работы LN

[DevilOper]

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

Прикинь, да) В битке то алгоритм консенсуа как раз решает эту проблему помимо других. если бы ты разобрался, то понял как) Так что ответ не защитан.
tcp уже сам по себе является тем протоколом, который решил эту проблему, в отличии от udp, но он не решает проблему репликации, журнала, консенсуса, как хочешь назови.

Вот если бы ТЫ РАЗОБРАЛСЯ - то понял бы, что ни в битке(с), ни tcp эту проблему, по сути, не решил(с), они просто городят подпорки вокруг неё, тем самым уменьшая вероятность; и всё то же самое так же прекрасно реализуется и с udp, только на уровне чуть выше - приложения.

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

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

Общие правила для протокола (примерно):

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

На этом - всё.

Спасение утопающих - дело рук самих утопающих(с)

Ты можешь забанить - повторю ещё раз - у себя, на своей ноде любую другую ноду по каким тебе угодно правилам. Хоть все ноды. Либо можешь просто не пересылать сообщения - тогда для всей остальной сети ты просто "уйдёшь в оффлайн", и всё.

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

Это не блокчейн придумал и это слово появилось очень давно, и просто является правилами для проведения сделок.
Первые идеи умных контрактов были предложены в 1994 году Ником Сабо

Опять "эрекция, эякуляция".

Да хоть Святыми Фомой и Ефросиньей.

Ещё раз спрашиваю, мне твой "умный контракт" полы помоет, или хотя бы сосиску сварит?
Я уж не говорю о более сложных действиях.

Пока ты не решишь проблему офлайн кошелька, твоя идея мертва.

"Пока ты не высунешь голову из лохчейна, твоя голова мертва", - как-то так.

Вы почитайте и узнаете, я удосужился и почитал, есть много статей и видео по теме работы LN

Нахаваться говна рекламных базвордов - это не "узнать", это нахаваться говна нахаляву.
Поверх tcp ты не реализуешь "атомарную операцию" от слова "никак". (Ну, в udp можно запись в сокет натянуть на "атомарную операцию" - при условии, если вас не интересует результат(с).)
Даже в пределах CPU "атомарной" будет либо одна единственная команда (далеко не любая), либо серия - но при условии отсутствия ветвлений, других потоков и запрета hw и sw прерываний.
Любая другая "атомарная операция" - не более, чем словоблудие и попытка наебалова.

[kzv]

1. Если транзакция адресована тебе - проверяешь, подтверждаешь, отпраляешь подтверждение отправителю и (условно) трём нодам с наиболее близкими к твоему адресами и наиболее близкими к адресу отправителя.

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

[lapitsky]

1. Если транзакция адресована тебе - проверяешь, подтверждаешь, отпраляешь подтверждение отправителю и (условно) трём нодам с наиболее близкими к твоему адресами и наиболее близкими к адресу отправителя.

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

У меня енот и еж. А у владельцев денег спустя время откат и бан моего адреса. И что делать будешь?

Ты можешь забанить - повторю ещё раз - у себя, на своей ноде любую другую ноду по каким тебе угодно правилам. Хоть все ноды. Либо можешь просто не пересылать сообщения - тогда для всей остальной сети ты просто "уйдёшь в оффлайн", и всё.

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

Прикинь, да) В битке то алгоритм консенсуа как раз решает эту проблему помимо других. если бы ты разобрался, то понял как) Так что ответ не защитан.
tcp уже сам по себе является тем протоколом, который решил эту проблему, в отличии от udp, но он не решает проблему репликации, журнала, консенсуса, как хочешь назови.

тоесть pow не решили? лол, опиши мне пример проблемы византийских генералов в битке

[DevilOper]

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

У меня енот и еж. А у владельцев денег спустя время откат и бан моего адреса. И что делать будешь?

Ну смотри. Между покупкой ежа и покупкой енота за углом проходит время. Скажем, пара минут даже на то, чтобы просто завернуть за угол, не считая сетевого обмена.
Собщения же по сети - распространяются практически мгновенно, считанные секунды. Ты даже отойти от продавца не успеешь, не то, что за угол завернуть.
Это раз. И два - это то, что три "копии" своей транзакции ты должен отправлять по ближайшим к своему адресам. Если отправишь по другим - ну, их получатели перенаправят, куда надо, это очень быстро делается. И кроме того, второй продавец (как, впрочем, и первый) - ждёт подтверждения от них же. Это пара секунд, буквально, даже с gprs модемом - там не гигантские объёмы данных. Т.е., в пределах считанных секунд второй продавец получит на твою транзакцию сообщение: "попытка дабл-спенда". Ну, а дальше-то уж конечно ему решать, как на это реагировать. Может и принять у себя, конечно - только после этого его счёт так же невалидным станет.

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

Я вот уже не знаю, какими словами писать, чтобы ты понял.
Общие правила - я написал. "Общесетевой бан" - нет такого понятия в этом алгоритме, он там нафиг не нужен. Хотя бы по той простой причине, что "спамить" ты можешь только одну конкретную ноду, ну или несколько нод - но никто в здравом уме и твёрдой памяти твой спам дальше транслировать не будет. Твой список - да ставь галочки там, где ты хочешь.

ПыСы. Вообще, есть спам, есть флуд, есть фрод и есть ддос. Ты зачем-то валишь всё это в одну кучу - но при этом почему-то требуешь от меня конкретных ответов на свой ответ.

тоесть pow не решили? лол, опиши мне пример проблемы византийских генералов в битке

Естественно, не решил.
Иначе, никто бы не орал: "ждать джва года шесть блоков сверху". Кривой костыль, не более.

[lapitsky]

Я вот уже не знаю, какими словами писать, чтобы ты понял.
Общие правила - я написал. "Общесетевой бан" - нет такого понятия в этом алгоритме, он там нафиг не нужен. Хотя бы по той простой причине, что "спамить" ты можешь только одну конкретную ноду, ну или несколько нод - но никто в здравом уме и твёрдой памяти твой спам дальше транслировать не будет. Твой список - да ставь галочки там, где ты хочешь.

Я не понял, у тебя соседние ноды/сиды только должны знать о транзакции? допусти 1 нода дружит с 2,3,4 и они вместе образуют кластер? тоесть 10000 нода, должна просто связаться с этими 5ю и больше ни с кем?

Ну смотри. Между покупкой ежа и покупкой енота за углом проходит время. Скажем, пара минут даже на то, чтобы просто завернуть за угол, не считая сетевого обмена.
Собщения же по сети - распространяются практически мгновенно, считанные секунды. Ты даже отойти от продавца не успеешь, не то, что за угол завернуть.
Это раз. И два - это то, что три "копии" своей транзакции ты должен отправлять по ближайшим к своему адресам. Если отправишь по другим - ну, их получатели перенаправят, куда надо, это очень быстро делается. И кроме того, второй продавец (как, впрочем, и первый) - ждёт подтверждения от них же. Это пара секунд, буквально, даже с gprs модемом - там не гигантские объёмы данных. Т.е., в пределах считанных секунд второй продавец получит на твою транзакцию сообщение: "попытка дабл-спенда". Ну, а дальше-то уж конечно ему решать, как на это реагировать. Может и принять у себя, конечно - только после этого его счёт так же невалидным станет.

1. А вот и нет. Если у тебя до 1млн кошельков/сидов/нод (это те которые онлайн, про офлайн позже),тогда физически посчитай, сколько займет время, чтобы в двух разных концах узнали, что у тебя на кошельке уже нет потраченных денег.  (если у тебя дружат, только 5 соседних нод и образуют кластер, другая история. жду ответ на предыдущий вопрос.)

Правильно я тебя понял, что каждая транзакция у тебя будет 2 минуты?

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

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

А ты так говоришь или кодил отправку сообщений по сети? Я кодил. когда уже 100 компов, которые могут отвалится, надо проверить обратно связь, записать данные в журнал, записать данные в вектор от кого получил, когда итд. это смерть. это не просто выкачивать файл по списку ip адресов и проверять его хеш. это совсем другая история. если рассмтаривать классические консенсусы и их скорость, так они  в системе, где все сервера заведомо доверенные.

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

ну смотри, ты отправляешь адресатам, а каждый следующий адресат должен знать кому уже отправляли, чтобы повторно не спамить обратно. тоесть должен быть вектор уже тех, кто знает о том, кто получил данные по трназакции. я не поленился и посчитал самую сырую транзакцию без доп информации:
Это пример примитивной транзакции без доп инфы в байтах (отпарвитель, получатель, сколько отправляем, комиссия, хешб timestamp)

Code:

[i]Ђ}q (X	   timestampq
GAЦЖv„‰ lX   numqK
X   fromqX   4SzkNXVjE9tFhBJWYKLPFfKcqxSYqX   toqX   U12cyWUQMYBtFnuMCjrr2FmCfnSqX	   count payqX   0.0003qX	   comissionq	X   0.000003q
X   hashqX@   8ecec0f992e7ea2c4ced01ed0d64dc09ba508ff4673dec8747cd864483010a02qu.
[/i]

берем ее и умножаем на 1000. Получается что 1000 нода в тсвоей системе, для получения транзакции должна выкачать 300кб. каждая предыдушая 299, 298 итд.
Это адова медленная скорость будет в твой системе. просто нереал.

И кроме того, второй продавец (как, впрочем, и первый) - ждёт подтверждения от них же.

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

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

как второй продавец получит инфу о попытке даблспенда в считаные секунды, если нод/сидов 10000. технически через цикл ты пробовал это делать? я не говорю про сервера на оптоволокнке в дата центре гугла. я говорю про tcp и компы в разных концах страны. чушь не неси. напиши простой скрипт, хотяб на zeromq, и посмотри на скорость отправки и приема 1000 сообщений между 100 компьютерами децентарлизованно. pow не синхронизирует ноды, он просто всем нодам говорить, что одновременно выкаичвать. в твоем случае выкачивать надо одновременно все и от всех. это ад.

ПыСы. Вообще, есть спам, есть флуд, есть фрод и есть ддос. Ты зачем-то валишь всё это в одну кучу - но при этом почему-то требуешь от меня конкретных ответов на свой ответ.

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

Не хочешь, не отвечай

Естественно, не решил.
Иначе, никто бы не орал: "ждать джва года шесть блоков сверху". Кривой костыль, не более.

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