Lightning Network

[QWeB]

Я тоже провёл очередные тесты сети!
Замерял скорость транзакций (на бытовом уровне, конечно). Выборка 5 микро-платежей различным получателям, маршрут не менее 3х каналов (не менее двух транзитных нод).
Средняя скорость прохождения платежа 115 секунд (от 25 секунд до 156 секунд).  

Начальной точкой платежа каждый раз был кошелёк Eclair, далее канал до моей ноды (LENINGRAD), а далее как пойдёт.

А отчего так долго? 156 секунд многовато как мне кажется для LN. С чем это связано по твоему?

Когда происходит какая либо активность, у меня на ноде активно начинает работать винчестер. Возможно, не все данные кэшируются. Но простые удалённые запросы к ноде через SSH, например, получить список всех каналов, занимают не более 5 секунд.
Могу дополнительно сказать, что платёж за "наклеечку" от Blockstream, который я проводил два месяца назад, прошёл за 10 секунд. Тогда я платил со своей ноды напрямую, не через Eclair. Маршрут был не менее одной транзитной ноды.

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

[leonello]

Когда происходит какая либо активность, у меня на ноде активно начинает работать винчестер. Возможно, не все данные кэшируются. Но простые удалённые запросы к ноде через SSH, например, получить список всех каналов, занимают не более 5 секунд.
Могу дополнительно сказать, что платёж за "наклеечку" от Blockstream, который я проводил два месяца назад, прошёл за 10 секунд. Тогда я платил со своей ноды напрямую, не через Eclair. Маршрут был не менее одной транзитной ноды.

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

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

[ttg43]

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

[amaclin1]

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

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

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

[kzv]

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

[amaclin1]

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

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

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

[Justice0881]

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

[amaclin1]

...так называемых «оракулов» — доверенных сущностей, которые выполняют роль проводника данных в смарт-контракты...

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

[QWeB]

...так называемых «оракулов» — доверенных сущностей, которые выполняют роль проводника данных в смарт-контракты...

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

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

[voron83-05]

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

[kinki32]

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

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

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

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

[amaclin1]

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

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

[kzv]

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

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

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

[amaclin1]

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

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

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

[GGUL]

Но простые удалённые запросы к ноде через SSH, например, получить список всех каналов, занимают не более 5 секунд.

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

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

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

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

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

[leonello]

Но простые удалённые запросы к ноде через SSH, например, получить список всех каналов, занимают не более 5 секунд.

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

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

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

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

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

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

[GGUL]

Но простые удалённые запросы к ноде через SSH, например, получить список всех каналов, занимают не более 5 секунд.

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

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

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

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

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

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

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

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

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

[amaclin1]

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

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

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

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

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

[GGUL]

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

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

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

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

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

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

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

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

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

[amaclin1]

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

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

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

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

Создатели LN  декларировали, что их система гораздо лучше с точки зрения конфиденциальности, чем блокчейн.  Поэтому мне интересно, получится ли у них это реализовать без уступок в этом аспекте.

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

Например, я запускаю 100 нод. Эти ноды по очереди, раз в 100 секунд инициируют
запрос про состояние каналов. Чтобы не выглядело, как спам.

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

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