Topic: Lightning Network - page 48. (Read 916677 times)

Не знаю, я не из России.

А во сколько оцениваются финансовые потери? Ну вот скажем если пополнять через сбербанк онлайн.

Нет. Сам кошелек подключил к ноде ACINQ. Потом пошел на сайт Битрефилла, создал заявку на пополнение, и отправил платеж. То есть, без танцев с бубном, все буквально в пару кликов.

Менее двух секунд.  

Подскажите, пожалуйста, вы напрямую к Битрефилу канал подключили? Сколько примерно секунд занял платёж?

Поддержу на словах! (свободные мериты уже все раздал )

+1

Ну а как иначе? Это же типичный дбаунтист.

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

Хоть бы писали что-нибудь стоящее. Так нет же! Хуйня-хуйней и околесицей намазана!
Вот вам список постов этого медиопея, я бросил беглый взгляд на это и меня вытошнило.
https://bitcointalksearch.org/user/mediopay-2143458

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

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

Спасибо за статью.
Кстати, сегодня установил Bitcoin Lightning Wallet, открыл канал на ~0.005 ВТС и пополнил себе телефон на Bitrefill.com.  

Сайт кошелька: http://lightning-wallet.com
Мейл разработчика (да, он русскоязычный): [email protected] 

Чем объясняется централизация лайтинг нетворка..? Пользователям важны низкие комиссии и что бы их средства никто не спер. Лайтинг это всё прекрасно обещает. В чем централизация? И чем она может по идеи помещать?

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

Чтоб не допустить централизацию Биткоина, мы построим над ним второй  слой. И ничего страшного, что он будет ЦЕНТРАЛИЗОВАННЫЙ.  
А чтобы он (LN) все-таки заработал, мы еще добавим кредитование. То есть, еще и вернем необходимость доверия 3-й стороне.

p/s/ Прочитал по диагонали. Не совсем понял основную идею. Может и ошибаюсь насчет кредитования.

https://twitter.com/verretor/status/1003518112942252039

Вот, на мой взгляд, интересная статья на тему развития LN:
https://medium.com/@homakov/xln-extended-lightning-network-80fa7acf80f3
Написано не по-нашему, но много картинок из которых и так становится понятна основная идея.

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

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

Хотел бы тоже немного пояснить:
Я там выше писал про запрос каналов, это я имел ввиду просто вывести текущее состояние МОИХ каналов, а не всех каналов сети. Просто как пример времени отклика моей ноды на команды.
Как осуществляется маршрутизация в LN написано тут: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
Если будет время, постараюсь сделать краткий перевод.

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

А если владелец маршрутизирующей LN-ноды может получить информацию, то конфиденциальности нет.
На данный момент, насколько можно судить по имеющейся информации, алгоритм примерно таков:
Отправитель запрашивает сведения о каналах
Сам вычисляет маршрут.
Запускает транзакцию.
При этом промежуточные узлы знают только откуда пришла транзакция и по какому каналу отправить дальше. Не знают начала и конца маршрута. С конфиденциальность вроде бы все нормально.
Хотя, первый узел наверняка будет знать, кто отправитель. А последний будет знать, кто получатель. Если отправитель и получатель - конечные пользователи.


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

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


7 транзакций в секунду для биткойна - это ограничение из-за объема блока, а не из-за
пропускной способности сети, так что я пока не исключаю, что в лайтнинге
построение маршрута все-таки решабельная задача. С учетом какого-нибудь
кэширования - тем более.


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

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

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

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

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

Тут всплывает еще такая интересная тема.
Обязанность узлов давать информацию о своих каналах необходима для постройки маршрута. И такой запрос сейчас реализован в протоколе. Насколько это вяжется с конфиденциальностью.
Например, я запускаю 100 нод. Эти ноды по очереди, раз в 100 секунд инициируют запрос про состояние каналов. Чтобы не выглядело, как спам.
В результате я получу снимки всей системы в каждую секунду, с какой-то погрешностью. То есть, буду знать, как каждый канал менялся. И может быть так , что с 99% вероятностью можно будет восстановить все платежи.

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

Не уверен, что это решение оптимальное и эффективное, но по крайней мере не требует полной
карты маршрутов.

А это кого-то ебёт? Вот так, по настоящему - вас это насколько сильно напрягает?

А как без информации о каналах построить маршрут. И кто за тебя будет искать маршрут? Вы же, как пользователи системы, в равных условиях.

Опять же, тому, кто будет искать, тоже нужна информация о всех каналах. А эта информация меняется каждые 2млн/24/60/60 - 2300 раз в секунду.

Это один момент. Второй момент - поиск маршрута 3-й стороной  это потеря конфиденциальности. Считай, что эта 3-я сторона будет знать все твои транзакции.