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

[DevilOper]

Я конечно не е*у как это большинство вычислить, но и ты не выкатывал никаких алгоритмов его вычисления.

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

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

[kzv]

Ещё раз:

1. Отправитель отправляет транзакцию 3-м ближайшим к своему адресам и 3-м ближайшим к получателю.

Пусть один из этих адресов (ближайший к получателю) оказался хакерским. И для определенности

Code:

tx=1, sum=100, from=kzv, to=DevilOper, sign=kzv_sign

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

Хакерский узел все делает по правилам кроме одного: он не коммитит транзакцию в свой блокнот.
В итоге: 5 нод записали в свой блокнот "коммит.тхт" транзакцию, получатель записал ее туда же. Хакер ее туда не записал.

Через час происходит следующее:
1.1 Отправитель через хакерские ноды отправил самому себе ту же самую транзакцию. Хакерские ноды ее закоммитили.

Code:

tx=1, sum=100, from=kzv, to=kzv2, sign=kzv_sign

Теперь в сети есть две валидные закомиченные транзакции с одним и тем же номером.

Через два часа:
1.2 Первый получатель отправляет транзакцию 3-м ближайшим к своему адресам (один из которых хакерский) и 3-м ближайшим к получателю.

Code:

tx=1, sum=100, from=DevilOper, to=DevilOper2, sign=DevilOper_sign

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

2.3. Убедившись, что у этих 6-х в "мемпуле" (поскольку она ещё не закончена) одна и та же транзакция - принимает её и завершает, отправляя по тем же адресам потверждение транзакции АКА commit. Внезапно: одна из шести нод (хакерская) сказала, что у нее в мемпуле нет такой транзакции.

2.4 Либо, не получив надлежащего удостоверения от этих 6-х - не отправляет подтверждения/отправляет отказ, транзакция "откатывается" (АКА rollback transaction, если ничего не отправил - то по таймауту)."
Ну вот и заебись: DevilOper получил от kzv 100 коинов, отправил ему взамен 100 баксов, но со своими законными 100 коинами DevilOper больше ничего сделать не может  

[DevilOper]

Через час происходит следующее:
1.1 Отправитель через хакерские ноды отправил самому себе ту же самую транзакцию. Хакерские ноды ее закоммитили.

Через какие ещё "хакерские ноды"?

2.3. Убедившись, что у этих 6-х в "мемпуле" (поскольку она ещё не закончена) одна и та же транзакция - принимает её и завершает, отправляя по тем же адресам потверждение транзакции АКА commit. Внезапно: одна из пяти нод (хакерская) сказала, что у нее в мемпуле нет такой транзакции.

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

DevilOper получил от kzv 100 коинов, отправил ему взамен 100 баксов, но со своими законными 100 коинами DevilOper больше ничего сделать не может  

Я бы имена местами поменял - поскольку, DevilOper всё же не такой идиот, чтобы что-то кому-то отправлять без получения подтверждения, которое занимает считаные секунды.

[kzv]

Через час происходит следующее:
1.1 Отправитель через хакерские ноды отправил самому себе ту же самую транзакцию. Хакерские ноды ее закоммитили.

Через какие ещё "хакерские ноды"?

Которые я сам запрограммировал и запустил на серверах у которых адреса наиболее близкие к жертве.

2.3. Убедившись, что у этих 6-х в "мемпуле" (поскольку она ещё не закончена) одна и та же транзакция - принимает её и завершает, отправляя по тем же адресам потверждение транзакции АКА commit. Внезапно: одна из пяти нод (хакерская) сказала, что у нее в мемпуле нет такой транзакции.

А какая есть? Если предыдущая - ну, дополнительный пакет отправителю: "чёзахуйня?тывонтомуидиотуотправлял?" Или что-то в этом роде.

Ответ: нет не отправлял. Первый раз про него слышу. Дальнейшие действия?

А если другая с тем же номером и подписью отправителя - ну, тогда с отправителем всё однозначно.

Ну и что. Пусть есть другая с тем же номером от kzv.
Ну да, теперь с отправителем kzv все ясно. Но прошло 2 часа и kzv успел пробухать 100 баксов DevilOper. А DevilOper теперь про kzv все знает, но ничего со 100 коинами сделать не может. Или сможет? Расскажи что делать дальше?

[DevilOper]

Которые я сам запрограммировал и запустил на серверах у которых адреса наиболее близкие к жертве.

Тут я тебе тоже пожелаю, как и твоему туповатому друКу, немедленно начианть подбирать ключи к "жырным" кошелькам беткоэна.
Ей-богу, выгодней будет, чем тут нам дурку включать.

Ответ: нет не отправлял. Первый раз про него слышу. Дальнейшие действия?

Ну, вообще-то, ответ от него может быть только один: переотправить транзакцию. Да и у остальных двух, собственно, она уже есть - могут и они переотправить. А тот, кто будет настойчиво тупить - просто помечается, как off-line/out-of-service.
Никаких "первый раз слышу" в протоколе не предусмотрено: либо отправил и подписался, либо не отправил - значит, не было.

Ну и что. Пусть есть другая с тем же номером от kzv.
Ну да, теперь с отправителем kzv все ясно. Но прошло 2 часа и kzv успел пробухать 100 баксов DevilOper. А DevilOper теперь про kzv все знает, но ничего со 100 коинами сделать не может. Или сможет? Расскажи что делать дальше?

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

[kzv]

Которые я сам запрограммировал и запустил на серверах у которых адреса наиболее близкие к жертве.

Тут я тебе тоже пожелаю, как и твоему туповатому друКу, немедленно начианть подбирать ключи к "жырным" кошелькам беткоэна.
Ей-богу, выгодней будет, чем тут нам дурку включать.

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

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

Ответ: нет не отправлял. Первый раз про него слышу. Дальнейшие действия?

Ну, вообще-то, ответ от него может быть только один: переотправить транзакцию. Да и у остальных двух, собственно, она уже есть - могут и они переотправить. А тот, кто будет настойчиво тупить - просто помечается, как off-line/out-of-service.
Никаких "первый раз слышу" в протоколе не предусмотрено: либо отправил и подписался, либо не отправил - значит, не было.

Переотправить закоммиченную транзакцию я правильно понял? То есть транзакция опять идет в мемпул?
Прекрасно, в этот момент хакер тоже посылает такую же даблспенд транзакцию в мемпул. Дальнейшие действия?
А вспомнил: дальше мы баним хакера и отменяем обе транзакции! Отличный протокол ))

[Vtools]

Второй алгоритм.
Цель - достичь следующей возможной ситуации: допустим мы планируем пойти в магазин за покупками, мы знаем что он принимает криптовалюту. Мы хотим быстро оплатить товары не ожидая 10 минут на кассе.
Решение:
Используем транзакции, применяемые в атомарном свопе. Но немного модифицированные. Порядок действий будет такой:
1. Покупатель заранее создает специальную транзакцию - депонирование суммы на счет продавца, т.к. он точно не знает суммы покупки, то отправляет немного больше, например 5000 руб.
2. Покупатель указывает время, когда деньги автоматически вернуться ему на счет, если он передумает покупать. Например через 2 часа (один час на хождение по магазину, 1 час - гарантия подтверждения транзакций блокчейном - точное минимальное значение задает продавей, например, в виде объявления при входе в магазин вместе со своим адресом кошелька)
3. Отправив транзакцию, покупатель ждет некоторое время, убеждается что его транзакция принята блокчейном и отправляется за покупками
4. При оплате покупатель предъявляет кассиру только специальный ордер (на самом деле это тоже транзакция только с другим содержанием), в котором указана сумма не больше депонированной и цифровая подпись. Продавец может самостоятельно отправить этот ордер, т.к. деньги фактически уже находятся на его счете. Ордер нужно отправить в сеть для того чтобы деньги не вернулись обратно покупателю. У продавца для этого есть достаточно времени, т.к. он это потребовал в виде объявления на входе (оно может быть как 1 час, так и 1 сутки)

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

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

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

Вот только что-то мне подсказывает что все это сильно похоже на платежные каналы в LN

[fxpc]

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

Я ему об этом ссылку на документ прислал, но он видимо не читатель.

[DevilOper]

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

Я ему об этом ссылку на документ прислал, но он видимо не читатель.

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

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

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

Ну да, не 400 миллиардов лет, а всего лишь 10 миллионов. Можешь начинать прямо сейчас: раньше сядешь - раньше выйдешь(с)

[DevilOper]

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

Вот только что-то мне подсказывает что все это сильно похоже на платежные каналы в LN

ДруК, "гарант" нужен только, чтобы что-то гарантировать: ну например, что деньги (фиат), которые ты ему дал на "подержать" - он никуда не проебёт мамой кланусь, да!.

Сам алгоритм от наличия присутствия либо отсутствия в нём "гаранта" не становится более надёжным от слова никак.

И да, в LN используют ту же схему - я это говорил не раз - только в ублюдочном виде, и нихуя они тут не изобрели.
В гораздо более пристойном виде эту схему давно используют в (меж)банковских расчётах, года так примерно с 1500-го.

[kzv]

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

Ответ: нет не отправлял. Первый раз про него слышу. Дальнейшие действия?

Ну, вообще-то, ответ от него может быть только один: переотправить транзакцию. Да и у остальных двух, собственно, она уже есть - могут и они переотправить. А тот, кто будет настойчиво тупить - просто помечается, как off-line/out-of-service.
Никаких "первый раз слышу" в протоколе не предусмотрено: либо отправил и подписался, либо не отправил - значит, не было.

Переотправить закоммиченную транзакцию я правильно понял? То есть транзакция опять идет в мемпул?
Прекрасно, в этот момент хакер тоже посылает такую же даблспенд транзакцию в мемпул. Дальнейшие действия?
А вспомнил: дальше мы баним хакера и отменяем обе транзакции! Отличный протокол ))

?

[DevilOper]

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

Один - нет, надо, чтобы все три (мало трёх - сделаем пять).
(Точнее, по принципу "отрицания отрицания": надо, чтоб ни один не подтвердил транзакцию.)

[kzv]

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

Один - нет, надо, чтобы все три (мало трёх - сделаем пять).
(Точнее, по принципу "отрицания отрицания": надо, чтоб ни один не подтвердил транзакцию.)

Почему нет?
Еще раз поясни алгоритм действий:

1. Второй хороший получатель DevilOper2 спрашивает у ближайших соседей первого DevilOper: "есть ли у вас транзакция в которой DevilOper получил 100 коинов"?
2. 4 из пяти сказали есть, один сказал нет.
3. Второй получатель говорит всем пяти: "а ну ка отправьте эту транзакцию обратно в мемпул". Так чтоли?

Поясни - что именно делать в третьем пункте?

[DevilOper]

Короче, я понял вашу проблему. Вы своим организмом, измученным лохчейном, путаете транзакцию (которая обратима) и состояние счёта (АКА баланс).

A перечисляет N коэнов B - транзакция.

У B теперь есть N коэнов - состояние счёта.

Последняя транзакция и её подтверждение всегда хранится про запас, чтобы подтвердить состояние счёта при возникновении разногласий по поводу состояния счёта. Если разногласий нет - транзакцию никто повторно не спрашивает.
Если у большинства "соседей" текущее состояние счёта оканчивается транзакцией #123, а хацкерской ноды™ #122 - ну, у неё просто неактуальные данные и их не принимают в расчёт (в этом месте можно, например, вставить вмешательство какого-нибудь демона QoS, который решает на всякий случай продублировать данные ещё на одной-двух нодах, раз уж эта, судя по состоянию её данных, онлайн бывает эпизодически). Если #124 - все остальные "соседи" попросят им дослать недостающую транзакцию, чтобы актуализировать свои данные. Не дошлёт - значит, хакерская нода™ так и останется одна в уголочке со своим хардфорком фейковым состоянием.

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

[fxpc]

В момент атаки на условного пользователя все ноды с которыми он соединён будут хакерскими и вся твоя идея идёт по пи*де, это на много порядков дешевле чем майнить свою цепь в лохчейне. Ты бредишь, в торренте 20 лет назад ни*уя не придумали как защититься, самому протоколу ещё нет 20 лет, но блажен кто верует. Даже если вероятность прохождения даблспенда один к миллиону, то атакующему всё равно выгодно, так как стоимость атаки практически нулевая. Как ты отличишь хакерские ноды со специально подобраными адресами от остальных до того как тебя поимеют, если связи с остальными у тебя нет?

[DevilOper]

В момент атаки на условного пользователя все ноды с которыми он соединён будут хакерскими и вся твоя идея идёт по пи*де, это на много порядков дешевле чем майнить свою цепь в лохчейне. Ты бредишь, в торренте 20 лет назад ни*уя не придумали как защититься, самому протоколу ещё нет 20 лет, но блажен кто верует. Даже если вероятность прохождения даблспенда один к миллиону, то атакующему всё равно выгодно, так как стоимость атаки практически нулевая. Как ты отличишь хакерские ноды со специально подобраными адресами от остальных до того как тебя поимеют, если связи с остальными у тебя нет?

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

[kzv]

Короче, я понял вашу проблему. Вы своим организмом, измученным лохчейном, путаете транзакцию (которая обратима) и состояние счёта (АКА баланс).

A перечисляет N коэнов B - транзакция.

У B теперь есть N коэнов - состояние счёта.

Последняя транзакция и её подтверждение всегда хранится про запас, чтобы подтвердить состояние счёта при возникновении разногласий по поводу состояния счёта. Если разногласий нет - транзакцию никто повторно не спрашивает.
Если у большинства "соседей" текущее состояние счёта оканчивается транзакцией #123, а хацкерской ноды™ #122 - ну, у неё просто неактуальные данные и их не принимают в расчёт (в этом месте можно, например, вставить вмешательство какого-нибудь демона QoS, который решает на всякий случай продублировать данные ещё на одной-двух нодах, раз уж эта, судя по состоянию её данных, онлайн бывает эпизодически). Если #124 - все остальные "соседи" попросят им дослать недостающую транзакцию, чтобы актуализировать свои данные. Не дошлёт - значит, хакерская нода™ так и останется одна в уголочке со своим хардфорком фейковым состоянием.

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

У тебя первый абзац противоречит второму.
Сначала ты пишешь

Если у большинства "соседей" текущее состояние счёта оканчивается...

То есть ты описываешь новый консенсус: "получатель обязан принять транзакцию если большинство считает ее правильной".

А в следующем абзаце ты прям подчеркиваешь

надо, чтобы все соседи отправителя подтвердили сначала первому получателю первую даблспендную транзакцию, а затем - и второму

Дак давай уж определись с консенсусом в своем протоколе, иначе дальше говорить неочем.

[DevilOper]

У тебя первый абзац противоречит второму.

А ты предложения дальше начальных слов читаешь, или вообще только выборочно тут-читаем-тут-не-читаем-тут-рыбу-заворачивали(с)?

Патамушто опять:

Короче, я понял вашу проблему. Вы своим организмом, измученным лохчейном, путаете транзакцию (которая обратима) и состояние счёта (АКА баланс).

Дак давай уж определись с консенсусом в своем протоколе, иначе дальше говорить неочем.

И снова блохчейноголовые не только лишь все в силах высунуть остатки своих засохших мозгов из блохчейна.

[kzv]

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

Итак,
1. второй получатель DevilOper2 получает транзакцию в мемпул от первого DevilOper.
2. DevilOper2 спрашивает у ближайших к отправителю соседей записи в их блокнотах "коммиты" и "баланс".
3. Четверо сказали, что в коммитах есть транзакция к DevilOper от kzv. Номер транзакции 1, Баланс у DevilOper равен 100, вот подпись kzv.
4. Пятый сказал, что в коммитах нет транзакции к DevilOper от kzv.  Баланс у DevilOper равен 0
5. DevilOper2 спрашивает у пятого: а у тебя вообще есть транзакция 1? Может ты проспал просто?
6. Пятый отвечает: а вот и нихуя я не спал. У меня есть транзакция 1 от kzv к kzv2. Баланс kzv2 равен 100,  вот подпись kzv.

Что дальше делать будем?

[kzv]

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

7. DevilOper2 отказывается принимать транзакцию потому что

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

7. И в то же время, DevilOper2 примет транзакцию потому что

Если у большинства "соседей" текущее состояние счёта оканчивается транзакцией #123, а хацкерской ноды™ #122 - ну, у неё просто неактуальные данные и их не принимают в расчёт

Признайся наконец: ты кроме недобейсика в одинэсе ничего в жизни не программировал да?