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

Хотел бы тоже немного пояснить:
Я там выше писал про запрос каналов, это я имел ввиду просто вывести текущее состояние МОИХ каналов, а не всех каналов сети. Просто как пример времени отклика моей ноды на команды.
Как осуществляется маршрутизация в 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-я сторона будет знать все твои транзакции.

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

5 сек для 6000 каналов - это может и нормально.

Какой, в общих чертах, алгоритм этого действия. И как он будет себя вести с ростом количества нод и каналов.

Навскидку, если возьмем масштаб Визы - это порядка 200 млн. транзакций в сутки.
Что дает примерно 100 млн. пользователей. Количество каналов будет такого же порядка.

Если информация об одном канале будет ~100 байт, то 100 млн. каналов*100 = 10ГБ информации.
Если 200 байт, то уже 20гб.

Эту информацию надо собрать со всей сети и загрузить перед созданием транзакции. Сколько времени это может занять?

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

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

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

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

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

В итоге вернулись к тому без чего хотели начать... Во главе третьим лицом будет сидеть дядя или тётя и потирать свои загребущие ручки!

Проблема "Оракулов" не нова. Ей уже год на смарт-контрактах эфира. Но пока ничего более подходящего не придумано.

На фига вам децентрализованная сеть с "третьей стороной" в виде оракулов?
Оракул забесплатно работать не станет. Может станет, но недолго.

Массачусетский технологический институт (MIT) продемонстрировал экспериментальный вариант применения решения Lightning Network для сети биткоина с использованием смарт-контрактов. Об этом сообщает CoinDesk.
Новое решение было разработано в рамках Digital Currency Initiative (DCI), руководимой MIT и стартовавшей еще в 2015 году. Суть новой модели заключается в том, что транзакции осуществляются автоматически при наступления определенных событий извне, будь то прогноз погоды или текущий курс доллара США. Таким образом, новый подход позволяет не только обрабатывать «миллионы транзакций», но также делает этот процесс более комплексным.
Реализация такого подхода возможна благодаря использованию так называемых «оракулов» — доверенных сущностей, которые выполняют роль проводника данных в смарт-контракты. Для текущей демонстрационной версии системы исследователи MIT создали тестового оракула, транслирующего текущий курс доллара США, выраженный в сатоши.
Впервые идея подобного использования Lightning Network была предложена летом прошлого года бывшим сотрудником биткоин-стартапа Mirror Таджем Драйджа. Теперь эта идея, наконец, получила дальнейшее развитие и обрела форму прототипа с рабочим кодом.
Однако разработчики подчеркнули, что прототип решения носит сугубо экспериментальный характер, а потому его пока «не следует использовать с реальными деньгами».
В рамках этого проекта исследователи MIT уже опубликовали на GitHub реализацию для Lightning Network, получившую название lit. Дополнением к ней является код оракула.

А зачем слушать разговоры? Команда Core регулярно собирается в ирке и обсуждает
кто что будет делать к следующему релизу. В коммитах на гитхабе можно посмотреть
кто что делает. Логи ирка доступны на http://bitcoinstats.com ( только учтите, что надо
переключить канал на #bitcoin-core-dev )

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

Вообще ходили разговоры, что LN будет в майском релизе коры встроен.
Что-то мне подсказывает, что за 6 дней не успеют ))

Вы не любите кошек? -- Вы просто не умеете их готовить!

Какие кошельки "в массе своей" не поддерживают сегвит? BitcoinCore поддерживает,
Электрум - вроде бы тоже (я не пользуюсь). Что еще у нас относится к "массе своей"?
Биржевые кошельки? - Ну так это не кошельки, а депозиты. Или вы blockchain.info
имеете в виду? Ну, опять же - нет у них желания что-то менять пока и так хорошо.

Раньше конца следующего года рабочие решения ждать не стоит, я думаю. Segwit вон уже сколько принят, а кошели до сих пор в массе своей его не поддерживают. Сколько ни пытался LN хоть как-то пощупать - не получалось =\