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 прыжка - эдакий квадрат). Да, эта сеть не работоспособна "доказано математически".

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

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


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

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

Мне, конечно, приятно, что я в свои 52 года могу прогрессировать.
Но думаю, что и раньше мой подход был таким. Причина скорее в том, что Вы сейчас смотрите со стороны, не так предвзято.

Допущения там вполне дружат с реальностью. Навскидку, можете привести пример нереального допущения.
По мне, так, допущение в тесте, про 14 каналов каждого пользователя, это из области фантастики.

А можно получить разъяснения, каким образом тест доказывает, что математика статьи не работает.
1. Автор  предсказал длинные маршруты. Ты сам очень сильно удивился, что в тесте они получились длинными.
2. Каким образом провалы в маршрутизации опровергает утверждение автора, что маршруты не всегда существуют.
Вот если бы 100% маршрутов было найдено, тогда понятно. А если быть точным, даже это не опровергло бы выводы из статьи.

Да и тест то неполный. Там только 4% пользователей сделали транзакции. Для того, чтобы опровергнуть автора, который утверждает, что по мере эксплуатации сеть становится несбалансированной, нужно что каждый из пользователей сделал минимум по несколько десятков платежей.

У меня нет уверенности, что не найдется. Я такого не говорил.
Моя цитата:"Я не могу утверждать, что такого алгоритма не существует".
У меня нет уверенности, что найдется. Это другое утверждение.

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

Жили-были мыши и все их обижали. Как-то пошли они к мудрому филину и говорят:
— Мудрый филин, помоги советом. Все нас обижают, коты разные, совы. Что нам делать?
Филин подумал и говорит:
— А вы станьте ежиками. У ежиков иголки, их никто не обижает.
Мыши обрадовались и побежали домой. Но по дороге одна мышка сказала:
— Как же мы станем ежиками? — и все побежали обратно, чтобы задать этот вопрос мудрому филину.
Прибежав, они спросили:
— Мудрый филин, а как же мы станем ежиками?
И ответил филин:
— Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь.

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


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


А откуда такая уверенность что не найдется? Пока что у лайтнига вообще нет никаких проблем (кроме того маленького недоразумения что он вообще еще не запущен; тестнет, очевидно, не в счет)  .


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

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

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

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

1. Вес ребер разный в 2-х направлениях
2. Задача немножко другая. Найти направленный маршрут, в котором вес каждого ребра в попутном направлении был не меньше заданной.
3. У того, кто решает, должна быть полная информация о графе. То есть о всех каналах в сети. Должен быть организован сбор информации.
3. Если смотреть пример выше, то 580 раз в секунду вес некоторых ребер меняется.
4. С какой-то вероятностью некоторые вершины и ребра могут исчезать из графа.

И задача в основном стоит найти маршрут за приемлемое время. А уж потом минимальный.

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

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


Это разве не решается в теории графов? По-моему, задача весьма классическая.
Есть граф с ребрами. У каждого ребра есть вес. Найти путь из вершины А в вершину Б по
ребрам чтобы суммарный вес был минимальным/максимальным. Можно еще и другие
метрики кроме веса учитывать, такие как количество ребер, то есть "три ребра по два" лучше
чем "два ребра по три"

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

Или  в LN ожидается какая-то другая топология сети, отличная от 3-й?

В остальном вся критика сводится к предположениям (читай надежда).

1. Будет найден хороший алгоритм маршрутизации
2. Каналы не будут дисбалансироваться.
3. Будет найден алгоритм маршрутизации, который попутно будет убирать дисбаланс.
4. Будет возможность один платеж распределять по нескольким маршрутам. То есть, вместо одного маршрута, мы научимся находить несколько маршрутов за те же секунды.
5  Сеть будет самообслуживаться. Ненадежные узлы будут убираться.

Особенно умиляет: "я не буду обсуждать математику."

Нелишним будет напомнить, что алгоритм маршрутизации плотно ищется уже где-то 2  года.
Чтобы оценить сложность задачи, приведу цифры.
Берем наш тест с 10 млн. пользователей. Предположим, каждый пользователь в среднем будет делать 5 платежей в сутки.
50млн платежей /24 / 60/60 - ~ 580 платежей в секунду.
После каждого платежа, ~20 каналов меняют свое состояние. То есть в каждую секунду ~10 тысяч каналов меняют свое состояние.  И алгоритм маршрутизации должен это учитывать. Мы не знаем, какой узел планирует делать платеж. Значит эта информация о состоянии каналов должна быть доведена до каждого узла. В каждую секунду.
И, 580 платежей в сек. - это не так уж много. Если планируется состязаться с Visa, то там пиковые нагрузки 50тыс. в секунду. Умножай цифры еще на 100.

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

Еще раз. В той статье автор взял изначально неработающую модель сети, доказал что эта модель не работает и зачем-то назвал эту сеть Лайтнинг. Вот каммент подробно показывающий что модель изначально выбрана неправильная, поэтому всеми дальнейшими "математическими доказательствами" можно только подтереться https://medium.com/@murchandamus/i-have-just-read-jonald-fyookballs-article-https-medium-com-jonaldfyookball-mathematical-fd112d13737a (и в догонку https://medium.com/@murchandamus/some-subsidiary-points-on-lightning-network-cc68bc81d6f1 )

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


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

Для каждого канала нужны 2 пользователя, поэтому все-таки по 14.

Отбросим термин "централизованный хаб", как непонятный. Лучше пользоваться терминами крупный, мега, мелкий.

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

Кстати, ты зря так критикуешь статью из темы. Там, на самом деле, вполне здравые рассуждения. Одна из глав  там именно это и доказывает, математически. Что если топология сети такая, как на 3-й картинке, маршруты будут ОЧЕНЬ длинными. Авторы теста только подтвердили это.

Тут есть загвоздка. Кофейне нет смысла открывать с тобой канал. Предположим у кофейни 100 постоянных клиентов. Чтобы с каждым открыть канал на 100$, кофейне нужно заморозить в каналах 10000.$. Зачем им это? Они могут открыть канал с крупным хабом на 1000$. Спокойно получать платежи. Когда наберут 1000, отправить одним платежом эту 1000 на биржу. И канал продолжает работать.

Что касается вопроса, насколько крупными будут хабы. Я нашел два серьезных фактора, подстегивающих укрупнение.
1. Для совершения одного и того же объема платежей  в сети с крупными хабами в каналах нужно замораживать меньший объем средств, чем в сети без хабов.
2. Чем мельче хабы, тем длиннее маршруты. Значит, тем дороже они будут обходиться для пользователей.

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

4. Крупные хабы могут эффективнее организовать работу. В режиме 24/7. Резервное электропитание, дублирующий выход в интернет. Резервный сервер. И т.д.
То, что обычному домашнему пользователю не потянуть.

Сеть с крупными хабами более эффективна в экономическом плане.

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

Кстати..

Если я ничего не путаю то на 10М нод всего открыто 70М каналов, то есть каждый пользователь по идее открыл 7 каналов, а не 14.


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


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



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


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


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


Опять же, все зависит от "аппетитов" этих жирных хабов. В отсутствии альтернатив/конкуренции логично ожидать накрутку комсы.

А в чем разница между "централизованными" хабами и "очень крупными" хабами?
Я не вижу.

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

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

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

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

Не знаю, где ты там увидел "нормально".  

Берутся практически идеальные условия. 10 миллионов пользователей, каждый вкладывает 0,14BTC  в систему.(Каждый из 10 миллионов имеет свободные 840$. Уже фантастика.)
Каждый открывает 14 каналов. (Зачем обычному пользователю открывать 14 каналов?)
На минуточку, это означает, что по каналу пользователь может заплатить не больше 60$. Только вдумайтесь, заморозить 840$, чтобы иметь возможность заплатить не больше 60$ за раз.
Чудесным образом эти каналы равномерно распределены по системе.
Практически, нереальные условия. Такого никогда не будет. Смысл тестировать на таких условиях.

Дальше веселее. При таких идеальных условиях   2.6%  микроплатежей были неудачными. Каждый 40-й платеж неудачно.  (Представьте, если бы каждый 40-й платеж по карточке VISA был неудачным. Удобно было бы и ею пользоваться?)
Это очень большой процент для идеальных условий.

Было смоделировано только 400 тысяч платежей. Это очень мало. С таким количеством и блокчейн справится. Ведь по мере платежей система все дальше уходит от идеальных условий, и после десятков,сотен миллионов платежей процент неудачных платежей может существенно вырасти.

А теперь предположим, что количество каналов уменьшится до разумных 3-6 каналов на пользователя. Пользователи будут вкладывать разные суммы в каналы.
Насколько вырастет процент отказа платежа. Если до 5% , то считай, система не имеет шансов на жизнь.

Тут я не совсем понял. 10 миллионов пользователей - не очень реалистичный сценарий?
Более реалистичный сценарий - 1 миллион пользователей. Что, LN рассчитан только на миллион пользователей?

Почему ты считаешь что сети именно "требуются" большие хабы? Ясный пень что они все равно будут (к сожалению я думаю у меня еще не скоро появиться возможность открыть канал к кофейне, так что да вначале конечно основными крупными узлами будут биржи всякие). Имхо крупные хабы возможно потребуются для задач перевода очень больших сумм через LN, но это как бы уже другая песня. Ну и вот статья где моделируют сеть без центральных хабов - всё норм https://hackernoon.com/simulating-a-decentralized-lightning-network-with-10-million-users-9a8b5930fa7a

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

Лол. Сколько можно постить этот бред. Там в камментах доказывают челу что он в принципе не понимает основ работы лайтинга, поэтому все его математические выкладки просто не имеют смысла так как изначально основаны на ложных допущениях. Вот пример нормальной статьи https://medium.com/the-litecoin-school-of-crypto/a-scale-free-and-private-lightning-network-e52a3c178d7d

День добрый!
Все мы слышали про сеть Lightning, но ни кому из нас не говорили,
Что работа этой сети не возможна в децентрализованный среде.
https://medium.com/@jonaldfyookball/mathematical-proof-that-the-lightning-network-cannot-be-a-decentralized-bitcoin-scaling-solution-1b8147650800