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

[DevilOper]

Зафига отправлять каким-то трем ближайшим

Затем, что так положено по протоколу.
Ну, ты лично можешь и не отправлять - сидеть тихо сам с собою то левою то правою рукою в тишине.

В биткоине отличить плохих от хороших очень просто: у кого блокчейн сложнее, тот и хороший.

Зафига проверять, у кого блохчейн сложнее?(с) как-то так.
Походу, ты уверенной походкой идёшь по стопам твоего туповатого трука.

[kzv]

Зафига отправлять каким-то трем ближайшим

Затем, что так положено по протоколу.

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

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

Проще  надо быть. Ближе к народу. И люди к тебе потянутся.

[DevilOper]

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

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

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

Аналогично.
Я не понимаю, в чём суть подобной "атаки".
Ну, не отправил ты транзакцию "соседям" - так её ни для кого и не существует, кроме тебя. И получатель ничего с ней сделать не сможет, если не спросил соседей, правльная ли транзакция - и не отправил им же подтверждение. Можете сколько угодно играться между собой - но потом только либо вернуться к изначальному состоянию, либо окуклиться и жить своей жизнью.

ПыСы. Отдельно вынесу:

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

Я, по-моему, миллион раз писал это скоро писалка отвалится: получатель по получении интересуется у этих соседей: а отправил ли отправитель? Не отправил - ну, так и нет твоей транзакции ни для кого.

[kzv]

Хорошо, я понял вроде тебя: получатель должен спросить у сети про валидность транзакции.

Шаг первый.
Алисина нода1 - Алисина нода2 - Валера (100 коинов, транзакция 1)
Алисина нода1 - Добра нода - Боб (100 коинов, транзакция 1)

Шаг второй
Боб - Добрая нода - Галя (получила 100 коинов)
Валера - Алисина нода3 - Галя (получила еще 100 коинов)

Продолжаем.

Шаг третий
Галя спрашивает у соседей: правильная ли транзакция от Боба?
10 добрых соседей сказали правильная. 1 злой сказал неправильная. Галя видимо транзакцию реджектит ибо проверить кто злой, а кто добрый она не может и должна думать о законе Мэрфи...

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

[fxpc]

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

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

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

[DevilOper]

... обсуждение даблспенда уже на 10 круг пошло.

Ну дак чукчинечитатели патамучто.
Ну вот, как пример:

Хорошо, я понял вроде тебя: получатель должен спросить у сети про валидность транзакции.
...
10 добрых соседей сказали правильная. 1 злой сказал неправильная.

Ведь 100500 раз писал же: что значит "сказал неправильная"?? Ну, так предъяви: либо с аналогичным или бОльшим номером, подписанную отправителем, либо другое какое доказательство "неправильности".
Блин, сколько ещё раз написать-то надо.

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

На торренты я ссылался исключительно в смысле скорости передачи/распространения транзакции, которая равна скорости поиска пира в DHT.

[DevilOper]

Как защититься от того, что пользователь вещает пирам разный value? (валидный)

"Разный" валидным быть не может - он либо устарел, либо одинаковый (либо невалидный вообще).

Как защититься от атаки большим количеством нод, которые отвечают на запросы пользователей несвежим value? (валидным)

Переведи.
Первый раз слышу об "атаке" ответами.

Как защититься от потери данных?

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

[fxpc]

Под валидным я подразумеваю value подписанный публичным ключом. К примеру, атакующий, используя свой ключ, одной ноде шлёт что этому ключу соответствует value 42, другой 100500, третьей 0. Какой из этих value истина? С чужими value можно провернуть такой же трюк, если хеш твоей ноды соотвествует запросам отвечающим за их ключи и ты сохраняешь старые value, а потом выдаёшь за свежие. Если майнер проебёт лохчейн, то встанет только запись, это не потеря данных. Забей на лохчейн и передачу цифровой пустоты, я говорю исключительно про децентрализованное хранилище данных.

[kzv]

Ну вот, как пример:

Хорошо, я понял вроде тебя: получатель должен спросить у сети про валидность транзакции.
...
10 добрых соседей сказали правильная. 1 злой сказал неправильная.

Ведь 100500 раз писал же: что значит "сказал неправильная"?? Ну, так предъяви: либо с аналогичным или бОльшим номером, подписанную отправителем, либо другое какое доказательство "неправильности".

Дак еж твою налево. Я уже на васях-петях описал все. Куда уж проще я не знаю

Шаг первый.
Алисина нода1 - Алисина нода2 - Валера (100 коинов, транзакция 1) <---валидная транзакция, но по хакерским нодам
Алисина нода1 - Добра нода - Боб (100 коинов, транзакция 1)

Шаг второй
Боб - Добрая нода - Галя (получила 100 коинов)
Валера - Алисина нода3 - Галя (получила еще 100 коинов)

Алиса отправила по своим нодам валидную транзакцию с правильным номером, с правильной подписью и вот этим вот всем.

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

[lapitsky]

итд.

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

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

В общем, проще всё онлайн делать, нахер все эти оффлайновые "холодне кошельки", это всё в беткоэне от безысходности.

пиздец товарищи, фейспалм, ахах  

Теперь он ту же транзакцию отправляет клиенту В. И опять отправляет её его (уже другим) соседям - и всё тем же самым своим.

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

Зафига отправлять каким-то трем ближайшим

Затем, что так положено по протоколу.

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

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

1. Ты можешь проверить подпись, а как ты проверишь сам счет? если ты хранишь только 1-2 транзакции. опять же если пару своих отвалилось в момент, как убедиться в валидности счета?

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

[Coin-1]

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

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

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

[DevilOper]

Под валидным я подразумеваю value подписанный публичным ключом. К примеру, атакующий, используя свой ключ, одной ноде шлёт что этому ключу соответствует value 42, другой 100500, третьей 0. Какой из этих value истина? С чужими value можно провернуть такой же трюк, если хеш твоей ноды соотвествует запросам отвечающим за их ключи и ты сохраняешь старые value, а потом выдаёшь за свежие. Если майнер проебёт лохчейн, то встанет только запись, это не потеря данных. Забей на лохчейн и передачу цифровой пустоты, я говорю исключительно про децентрализованное хранилище данных.

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

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

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

[DevilOper]

Алиса отправила по своим нодам валидную транзакцию с правильным номером, с правильной подписью и вот этим вот всем.

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

Дак еж твою налево.(с) кто-то в этой теме.

Ты чё, специально дурочку включил, подобно твоему друку?

Ещё раз: каким "своим нодам"??
По протоколу она обязана отправлять определённым нодам. Отправила другим - те обязаны переслать всё тем же определённым нодам. Ну, почитай, как DHT работает, в конце концов.

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

[kzv]

Алиса отправила по своим нодам валидную транзакцию с правильным номером, с правильной подписью и вот этим вот всем.

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

Ещё раз: каким "своим нодам"??

Еще раз: своим это тем, которые Алиса сама запрограммировала. Это хакерские ноды. Они все делают по протоколу кроме одного: Они не посылают информацию о второй валидной, хакерской, даблспенд транзакции с тем же номером никому кроме других хакерских нод. До тех пор, пока кто-то не захочет потратить первую валидную, нехакерскую, недаблспенд транзакцию.

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

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

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

[DevilOper]

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

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

[kzv]

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

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

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

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

[DevilOper]

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

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

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

1. Получил транзакцию
2. Проверил подпись.
3. Спросил у окружения про "подтверждаете ли, что у отправителя есть эти бабки"?
4.1. Если окружение сказало "подтверждаем", жду пару минут и считаю транзакцию подтвержденной

Nope.
Писал же 100500 раз, и вот только что ещё.
Отправляется подтверждение (АКА commit transaction). Получателем. Тому же "окружению".

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

Ну хорош уже дурочку-то включать.
Ещё раз повторяю: что значит "сказало"? Есть номер последней транзакции и текущий баланс. Если что-то не совпадает - так предъяви, что не совпадает-то.

5.2. Если доказательство есть - ... TODO: DevilOper

Неа - TODO: kzv:
Опиши мне эти твои гипотетические доказательства - а то, у меня чёта фантазия иссякла.

[kzv]

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


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

Code:

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

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

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


 

[DevilOper]

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


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

Code:

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

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

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

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

Ещё раз:

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

[fxpc]

Под валидным я подразумеваю value подписанный публичным ключом. К примеру, атакующий, используя свой ключ, одной ноде шлёт что этому ключу соответствует value 42, другой 100500, третьей 0. Какой из этих value истина? С чужими value можно провернуть такой же трюк, если хеш твоей ноды соотвествует запросам отвечающим за их ключи и ты сохраняешь старые value, а потом выдаёшь за свежие. Если майнер проебёт лохчейн, то встанет только запись, это не потеря данных. Забей на лохчейн и передачу цифровой пустоты, я говорю исключительно про децентрализованное хранилище данных.

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

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

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

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

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