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

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

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

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

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

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

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

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

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

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

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


?

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

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

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

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

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


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

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

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

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


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

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

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

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

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


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


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

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


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


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

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


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

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

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

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

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

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

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

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

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

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

В таблице хэш-значение ноды по одному ключу могут хранить полную х*ету или протухшие данные даже не намеренно, никакого консенсуса у них нет. В торренте это не является проблемой, потому что другой файл в отличии от протухшего или альтернативного баланса и прочих изменяемых данных не соответствует искомому ключу. Весь твой велосипед подвержен sybil атаке чуть более, чем полностью. Пруф: https://www.cs.helsinki.fi/u/lxwang/publications/security.pdf
Лохчейноголовые не от нечего делать нагородили всяких proof of что-нибудь, которые как выяснилось тоже не помогают на 100%, но без них и того хуже - чёрная дыра. Если бы данная проблема решалась твоим методом, то даже и DHT был бы не слишком нужен, храни себе таблицу у всех пиров и полагайся на позицию большинства. Я конечно не е*у как это большинство вычислить, но и ты не выкатывал никаких алгоритмов его вычисления.

Я блин для кого пишу-то.

Ещё раз:

1. Отправитель отправляет транзакцию 3-м ближайшим к своему адресам и 3-м ближайшим к получателю.
2. Получатель по получению соответственно запрашивает у 3-х ближайших к своему и 3-х ближайшик к отправителю. Как мы видим, это те же фаберже адреса, только в другом ракурсе.
3. Убедившись, что у этих 6-х в "мемпуле" (поскольку она ещё не закончена) одна и та же транзакция - принимает её и завершает, отправляя по тем же адресам потверждение транзакции АКА commit.
4. Либо, не получив надлежащего удостоверения от этих 6-х - не отправляет подтверждения/отправляет отказ, транзакция "откатывается" (АКА rollback transaction, если ничего не отправил - то по таймауту)."
5. После того, как транзакция завершилась - публиковать что-то "из бабушкиного сундука" совершенно бесполезно. Ибо: 1) а какого йуха ты не перенаправил эту транзакцию своевременно кому положено, и/или 2) какого йуха ты её принял, не получив нужных подтверждений (если ты получатель), и опять-таки, не разослал свой commit кому положено.
_________________________________
* Пункты: 2а., 2б. и тп., когда отпраитель/получатель отправляет "не тем" соседям: тут начинается "магия" DHT - ноды обычно "знают" своих соседей, и если у кого-то из соседей находятся более соседские соседи - они перенаправляют пакет туда, и сообщают адреса этих соседей отправителю.

Я тоже уже устал по 100 раз пояснять.
Давай тогда прямо тут твою сеть тестировать.


1. Я kzv подключен к 3 хорошим нодам, одна из которых подключена к тебе. У меня есть 100 коинов. Я их отпраляю тебе.


Три моих соседа приняли эту транзакцию, проверили, записали к себе в блокнот, отправили тебе.

2. Ты получил транзакцию. Проверил подпись. Дальше что?


 

Nope.
Писал же 100500 раз, и вот только что ещё.
Отправляется подтверждение (АКА commit transaction). Получателем. Тому же "окружению".
Ну хорош уже дурочку-то включать.
Ещё раз повторяю: что значит "сказало"? Есть номер последней транзакции и текущий баланс. Если что-то не совпадает - так предъяви, что не совпадает-то.
Неа - TODO: kzv:
Опиши мне эти твои гипотетические доказательства - а то, у меня чёта фантазия иссякла.

Процесс подтверждения по шагам в студию.
Я начну, ты поправь и дополни

1. Получил транзакцию
2. Проверил подпись.
3. Спросил у окружения про "подтверждаете ли, что у отправителя есть эти бабки"?
4.1. Если окружение сказало "подтверждаем", жду пару минут и считаю транзакцию подтвержденной
4.2 Если окружение сказало "у отправителя нет этих бабок", жду пару минут и считаю транзакцию фейковой
4.3. Если часть окружения сказало "есть", а часть сказала "нет". Иду в пункт 5.
5. У тех, кто говорит, что "нет у отправителя бабок", спрашиваю "какие ваши доказательства"
5.1. Если доказательств нет - действую как в 4.1
5.2. Если доказательство есть - ... TODO: DevilOper

Ещё раз: после того, как на первую получено подтверждение - вторая транзакция так там и останется у этих нод в аналах.