Topic: Сеть Lightning и децентрализация не совместимы. (Read 684 times)

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

Что мне надо имея "платежку" на руках? Построить граф, который соединит меня с кофейней
маршрутом каналов, на каждом из которых будет достаточно бабок. После этого запустить
со своей стороны процесс передачи используя свой приватный ключ. Да, согласен, какой-то идентификации
что "я - это я" не требуется, если реквизиты платежа будут содержать реквизиты чека. Но для этого кассир
в столовой должен сформировать "платежный чек", я его сканирую и отправляю платеж.
Вариант когда кассир говорит "Привет, Вася. С тебя 350 рублей как вчера", я вбиваю
350 рублей уже не подходит.


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

Зачем? Пришел официант отдал тебе чек. Ушел. Этот чек можешь оплатить ты, твой друг или тот парень за соседним столиком, если ты его заставишь это сделать (и молчать). Официанту пикнет что такой-то чек оплачен и ему по сути по барабану кто из вас его оплатил. И вы спокойно можете покидать ресторан. (но если в каком-то случае я оплатил такую платежку и мне нужно это доказать что это был именно я, то мне кажется это вполне реально). Вот тестнетовская кофейня https://starblocks.acinq.co/#/ (у мня в хроме не работает   - там в левой части должен быть список "товаров") там можно быстро (без СМС и регистрации) сформировать заказ из нескольких кофе. В платежке на сколько помню помимо прочего закодированы номер заказа и его состав (спецуха если вдруг интересно https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md ).

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

Платежка не привязана к каналу, но если у меня прямой канал со столовой (одно ребро графа)
и на канале достаточный депозит - то зачем мне пользоваться альтернативными маршрутами?
Пока не вижу в этом физического смысла, хотя не исключаю что он может присутствовать (поддержка балансов на каждом канале).
Платежка привязана к юзеру. Я должен как-то уведомить ресторан, что вот это бабло
на $1000 пришедшее с канала от Билла Гейтса на самом деле прилетело кружным путем именно от меня.


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

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

Я не к тому, что знаю как это остановить. Не знаю. Всё так или иначе стремится к централизации
до тех пор, пока "низы" не устраивают очередную революцию, перемешивают в хаосе богатых
и бедных и начинают процесс заново.

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


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

Да вот мне тоже казалось, что мы обсуждаем статью, которую оба читали.
Ты спросил где неверное предположение. Я вроде ответил - что в самой первой формуле, в которой реальности 0 (ноль). В дальнейшем он вводит в нее еще какие-то факторы но это все бессмысленно потому как формула изначально описывает нерабочую сеть. Поэтому предлагаю вернутся в самое начало.

По модели автора и 3 пользователя с 3 каналами нерабочая сеть. И 5 с 5-ю, и 10 с 10. В изначальной формуле нет ничего связанного с деньгами. Изначальная формула сразу описывает "рандомную" сеть которая "рандомно" не будет работать.


Автор доказывает что некая абстрактная рандомная сеть не работает. Нет никакой реальной связи его модели с тем что изображено на 3-м рисунке.

Еще раз 2-й  вариант изначально бред там нужно каждой точке добавить еще по 1 или 2 связи минимум. Если рассматривать 3-ю картинку, то как я уже и писал при желании и в ней можно увидеть "централизацию". Если предположить что бизнес действительно будет пытаться создать некую рабочую сеть которая очевидно будет неким "ядром" - то на 3-й картинке это скорее всего то что в в центре - узлы с 6-4 каналами, а пользователи там это по сути "переферия" с 2-3 каналами - если некоторых из них выключать/включать то не думаю что это будет как то сильно влиять на работоспособность сети в целом.

Ну, открыть канал это не "форточку открыть". Публичный ключ можно со стены сосканировать.
Но до оплаты официанту надо внести депозит и в какой-то момент каким-то образом
передать информацию о том что адрес 3xyzxyzxyzxyz - что это именно вы открыли канал и именно
с этим контрагентом.


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


Бабки не могут быть одновременно и вашими личными, и храниться на балансе канала.
То есть вы депонировали на канал с рестораном $5000, потом сходили в ресторан вдесятером,
каждый потратил по $100, но так как у ваших коллег не было своих каналов с рестораном,
они маршрутизировались через вас. В результате общее состояние системы поменялось:
у вас в канале на ресторан остался депозит на $4000, плюс ваши девять друзей должны вам
по стольнику.

И тут вы идете по улице и видите что продается люстра за $4500 о которой вы год мечтали.
Можете ли вы её оплатить сразу? Нет. Так как в канале на ресторан у вас осталось только
$4000, чтобы получить недостающие $500 вам надо закрыть пять каналов с друзьями, только
после этого вы можете по сути распоряжаться деньгами. Нах вам такое щастье? Вот чего ради
иметь такой гемор?

Комса тут не при чем, я пока что про нее вообще молчу.

Зачем такие сложности? Они публикуют свой ключ по которому любой желающий может открыть канал со столовой. Ок ты открыл. На далансе канала с твоей стороны например 50$, со стороны столовки соответственно 0$. Ты пришел в столовую набрал заказ тебе сформировали платежку на твой заказ на 10$ (она действительна для оплаты кем угодно через лайтнинг). Ты ее оплачиваешь. Баланс на канеле несколько изменился - теперь с твоей стороны на канале 40$, со стороны столовки - 10$. В этот смы момент канал уже двухсторонний. Столовка может отправить эти 10$ например даже через тебя (если твой узел маршрутизирует платежи) на какой-нибудь обменник например (т.е. они со свой стороны в теории могут долго не закрывать этот канал).

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

Что значит буду платить "за коллег"? У меня на баллансе узла всегда будут мои собственные свободные 5к. Если геморно за 3 копейки - ставь комсу выше  

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

Странно, мне казалось мы обсуждаем статью, которую оба читали?
гугл-цитата
 и т.д

1000 нод по 1000 каналов- это действительно нерабочая модель. Потому что, если у каждого пользователя есть 840$ свободных денег, то в каждом канале будет только 84 центов. Кому нужна такая сеть.

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

p/s/ Основная идея статьи (как я понял)
Автор берет топологию статьи, как на 3-й картинке и доказывает, что она нерабочая.

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

Если среднее количество каналов у пользователя высокое, то уменьшается размер депозита на каждом канале. Тогда сокращается количество доступных каналов для маршрутизации по причине нехватки средств на канале. Что тоже уменьшает вероятность существования маршрута.

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

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

Есть еще вариант:
У каждого обычного человека один канал. С большим хабом. А большие хабы соединены между
собой и со всякими столовыми. Остается назвать все своими именами. То есть вместо слова "хаб"
начать произносить слово "банк" и понять что вы только что "изобрели" обычную централизованную
банковскую систему.

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


Если система будет работать когда пользователю достаточно открыть всего 3 канала то ни каких 100500 каналов пользователей у столовки не будет. С админом это да.

ЛОЛ! Серьезно? Во-первых, его модель абсолютно точно моделирует не вероятность того что на каналах не будет средств. Но даже если вдруг предположить что это так то реально получается что сеть изначально тупо нерабочая и никакие даже централизованные хабы тут не помогут   (по его модели если взять что каждый узел будет иметь соединения со всеми остальными (1000 нод 1000 каналов на каждой - то есть минимальное расстояние меду любыми 2 участниками 1 хоп) - то ситуация даже ухудшится. Тестнет с такой фигней уже с первого для работы должен бы был загнутся, и все разрабы уже давно бросили бы это неработающее Г.

Нет моделирование как раз показывает что это в статье модель оторвана от реальности.  

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

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

Я еще не понял что есть вероятность отказа в данном случае. Но если вы приходите
в столовую и в магазин то каждый раз вы предъявляете кассиру транзакцию, которая списывает
с вашего депозита бабки. А магазин и столовка эту транзакцию где-то хранят у себя
в подсобном помещении. Раз в месяц (или когда заканчивается депозит) магазил и столовая
проводят единственную транзакцию перекидывая потраченное вами бабло себе на счет.
Если вы приходите в какое-то незнакомое место, допустим в ночной клуб, то чтобы расплатиться
вам достаточно иметь эту сумму на одном из трех своих депозитных счетов. А дальше
сеть пытается построить маршут вы->магазин->булочная->прачечная->консерватория->ночной клуб
или вы->столовая->мясокомбинат->обсерватория->казино->ночной клуб или
вы->банк1->банк2->ночной клуб.

Ваши фантики по-прежнему защищены силой математики. Но система получилась корявая
и неудобная. Будучи навернутой поверх существующего блокчейна мы имеем ту же проблему
атаки-51 которая никуда не делась. Плюс магазину и столовой надо хранить 100500 каналов
с каждым из своих покупателей. Причем владелец магазина по сути дела не защищен
от админа-злоумыщленника. Админ закрывает каналы, после чего переводит биткойн
на свой личный счет и уезжает на Багамы.

Возьмем 4 узла, соединенных квадратом
1 2
3 4

Возьмите узлы 2 и 3 по диагонали. Существует ненулевая вероятность, что эти два узла потратили все свои деньги. Тогда 1 и 4 по другой диагонали, хотя у них и есть  средства, не смогут сделать платеж друг к другу.
Или они перечислили свои деньги узлу 1. Тогда узел 4 не может перечислить узлу 1.
Или они перечислили свои деньги узлу 4. Тогда узел 1 не может перечислить узлу 4.

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

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

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

Там идет оценка, насколько минимальной может быть максимальная длина маршрутов для графа с заданными условиями: каждый узел имеет N каналов.

Для того чтобы оценить, берется один узел и от него строится/выделяется наикратчайший путь к КАЖДОМУ другому узлу. Если оставить ребра, которые попали в эти маршруты, то как раз получится древовидная структура. И дальше расчетным путем вычисляется, какой длины будут эти маршруты. Например для миллиона узлов с 10 каналами в каждом узле может быть граф, где все маршруты от одного узла к другим будут длиной меньше равно 6. И нельзя сделать граф, в котором все маршруты от одного узла ко всем другим будут меньше 6.

В дальнейшем эта длина маршрута используется для вычисления вероятности существования маршрута.

Да, в текущей реализации нельзя, но насколько я понял это в принципе реализуемо (влом искать цитату).

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


О! Мне кажется все же нужно как-то договорится что именно считать "централизованной сетью" в лайтнинге. Например для меня сеть будет являтся децентрализованной при условии 1. Я могу "легко" поднять свой узел. 2. Мне будет достаточно открыть всего три канала чтобы получить возможность как минимум отправлять платежи с очень низкой вероятностью отказа. 3. Ни у кого в сети нет возможности "увести" мои деньги. И покуда соблюдаются эти три условия мне абсолютно пофиг будут ли в этой сети огромные (типа "централизованные") хабы или нет, в целом я буду считать такую сеть "децентрализованной".

Я может неправильно понял (поправьте) но канал нельзя пополнить, можно
лишь закрыть (записать транзакцию в блокчейн) и потом открыть новый.
Хотя... Может и можно... Блин... Надо спеки читать, а не выдумывать...

Температуру забортной воды изменить не удалось по причине отсутствия таковой!
Логично, что проблем нет. У меня в программе тоже багов не было пока я её никому не давал запускать.

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

Тогда я жду попытку объяснить что же там за абстрактная модель сети описывается что даже с 4-мя пользователями соединенными квадратом и без каких либо дополнительных условий получается что сеть по сути не рабочая.

Так в том то и дело что в статье сеть сразу нерабочая (даже без доп ограничений) а в модели сеть с ограничениями уже более рабочая.


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


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

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

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

Да там не берется древовидный граф. С чего Вы это взяли?
Гугл-цитата из статьи.
Берешь любой узел на графе. Находишь наикратчайший путь от него к каждому узлу и красишь жирным. И ты получишь древовидную структруру. И эта структура выделяется из графа только для того, чтобы оценить, сколько  прыжков в среднем требуется, чтобы добраться до любого узла. Все дальнейшие расчеты уже от этого количества прыжков.
Так и не должны биться. Тест ведь сделан не полностью по статье. Как минимум, там берется, что все пользователи вкладывают по одинаковой сумме по 60$ в каждый канал. А платеж всегда меньше 60$. Это же практически идеальные условия. Любой платеж влезает в любой канал. Как они вообще умудрились при этом не найти маршруты, меня даже удивляет.
Если бы суммы вложенные в каналы, случайно распределялись от 10$ до 120$, то результат мог бы быть совершенно другим. Ведь для платежа в 60$ половина каналов была бы недоступна.
Еще в статье прогнозируется, что довольно существенная часть пользователей время от времени полностью тратить деньги. Что выключает их из маршрутизации. В реальной жизни так и происходит. Этот момент в тесте не учтен. Что-то подобное было бы, если бы каждый пользователь сделал несколько десятков рандомных платежей.

Мы этого доподлинно не можем знать.

Случайный рандомный древовидный граф? Самая первая формула на основе которой и строятся дальнейшие вычисления. Может я чего не понимаю, тогда объясни мне каким образом эта формула описывает реальную децентрализованную сеть всего из 4 участников (2 канала, 2 прыжка - эдакий квадрат). Да, эта сеть не работоспособна "доказано математически".

Дык, циферки не бьются.

Провалы в тесте связаны не с тем что маршрут не существует в принципе (как у автора), а то что на поиск маршрута были наложены ограничения (время, комса).


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