Topic: Lightning Network - page 8. (Read 915873 times)

У меня htop показывает загрузку 2%, при этом bitcoind на первом месте, lnd на втором. Ubuntu, LND 0.8.0. Мыслей нет.

Приветствую!
Я работаю над проектом, где мне надо запустить большое количество lnd нод (сервисов) на одной физической или виртуальной машине. В теории все кажется просто, сделать структуру директорий под каждую ноду со своим конфигом, своими портами и т.п. Все это получилось реализовать довольно просто и для теста я запустил 16 нод на одной виртуальной машине. (CentOS 7, если это важно)
После запуска каждая нода начиет обновлять "граф" сети (channel.db в /data/graph/mainnet); процесс это довольно долгий и требует процессорных ресурсов. После того как граф сети загружен, lnd сервис, по идее, должке перейти а idle режим ожидая транзакций и т.п. В действительности так и  происходит, но не на долго, сначала нагрузка на процессор снижается до десятых долей процента, но длится это не долго, через час-два сервисы, по одному, начинают грузить процессор отъедая все свободные ресурсы. Самое интересное, что сервис начав грузить процессор, загрузку не снижает уже никогда, вплоть до перезагрузки сервиса, сервисы бесконечно отжирают все свободные ресурсы уже через пару часов после запуска. Интересно то, что при этом загрузка сервиса bitcoind нулевая, т.е. сервисы не работают с базой блокчейн, а делают непонятно что. В логах все выглядит, как будто система работает нормально, ничего сверхестественного.
Я не понимаю, что происходит и как это пофиксить. Железо, которое используется в качестве хоста, довольно производительное. i3-3.8Ghz/16Gb RAM/SSD и говорить, что оно не справляется просто нельзя. Может кто-то уже с этим сталкивался. Нашел на github в  lnd проекте похожую issue и также создал свою, но на текущий момент результатов никаких нет.
https://github.com/lightningnetwork/lnd/issues/3370
Мне интересно послушать каждого, у кого есть мысли по поводу, что это и как можно пофиксить.

Он не мой. И лучше для каких целей?

Тогда почему Ваш вариант c отправкой мелкими суммами по разным маршрутам будет лучше?

Поздравляю! Сейчас так и работает.

Зачем отправлять сумму меньше, чем позволяет маршрут? Мне кажется, с таким же успехом можно пытаться отправлять ровно столько, сколько позволяет маршрут. Если не получится, то создавать другой и пытаться отправлять по ней. И так до победного конца.

Вродеб, выше было обозначено зачем? Чтобы противодействовать злонамеренной блокировке каналов. Об этом же говорим?

То есть, планируете разбивать суммы платежа на несколько частей и пропускать через разные маршруты, при этом размер суммы для маршрута будет заведомо меньше, чем этот маршрут позволяет? Зачем эти танцы с бубнами?

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

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

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

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

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

Фиксят обычно ошибки. В данном случае был реализован определенный алгоритм построения маршрута. И он был выбран таким исходя из каких-то благих соображений. Чтобы пофиксить, необходимо придумать другой алгоритм. А где гарантия, что у нового алгоритма не будет своих слабостей и уязвимостей?
 Например, решим, что маршрут в таком случае будет строиться по новой. Тогда необходимо отменить все уже сделанные блокировки каналов. А это время, потраченное каналами впустую. На ум сразу приходит злоумышленник, который строит маршрут, запускает его, блокирует N каналов, на N+1 канале отменяет, при этом выждав максимальную паузу. И в бесконечном цикле. И ноды ничего не могут сделать, ведь они не знают, кто запускает маршрут.

Чисто теоретически. Как построить надежную децентрализованную систему? Ведь в качестве аксиомы надо принять, что часть участников системы будут вести себя злонамеренно/деструктивно.
Первое, что приходит в голову, это распараллеливание действий. Запускаешь N процессов, если даже несколько из них попадут на деструктивного участника, то ничего страшного не произойдет, остальные сработают.  Так, как это устроено в блокчейне. Связываешься с 10 участниками, делаешь транзакцию и кидаешь всем. Или же майнеры, которые работают параллельно, а не последовательно.

Если, например, 10% узлов в Биткоине будут злоумышленниками. Тогда при подключении к 10 случайным нодам вероятность того, что  не получится отправить  транзакцию, составляет 0.1^10. То есть, практически, ноль.

А если же возьмем LN, у которого 10% процентов узлов злоумышленники. Тогда, при длине маршрута 5, вероятность того, что попадете на злоумышленника равна около 1/2.

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

QWeB, дык это все понятно. Изначально вопрос на сколько я понял стоял так: Если при открытии канала я не спешу и могу выбрать любую даже мизерную комиссию, вопрос, то можно ли при закрытии канала так же сэкономить.

Ок, любое некооперативное закрытие = commitment transaction, и тут я полностью согласен что комиссии этих транзакций должны считаться внутри кода.

Но при кооперативном закрытии канала не все так однозначно. Если сторона закрывающая канал никуда не спешит, то скорее всего другая сторона тоже. В крайнем случае если стороны (ноды) не могут договориться о комиссии закрытия канала, то да, в ход идет "commitment transaction". Цитата BOLT #2: "Nodes can negotiate a mutual close of the connection, which unlike a unilateral close, allows them to access their funds immediately and can be negotiated with lower fees." Вот тут я не против на счет того чтобы у пользователей была некая настройка минимальной допустимой комиссии (максимальная величина, очевидно равна комиссии последней commitment транзы).

Когда имплементация одного разработчика LN (например, c-lightning) с одной стороны автоматически устанавливала комиссии ниже диапазона возможных комиссий имплементации от другого разработчика LN (например, eclair) на другой стороне канала, это приводило к ошибке и автоматическому закрытию канала. Под "падением" подразумевается автоматическое закрытие канала вопреки воли тех, кто его создал, сугубо по техническим причинам.
Так-то комиссию нужно платить три раза за жизненный цикл канала (или два при кооперативном закрытии канала): при создании канала, при блокировке средств на смарт контракте, при возврате средств на свой кошелёк. Закрытие канала может инициировать любая из сторон, даже если вторая сторона не алё не он-лайн.

Попался на глаза тест Watchtowers (тестнет) с подробным гайдом для желающих повторить https://random.engen.priv.no/archives/635


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

В своё время было много падений каналов, связанных с отсутствием консенсуса по этим комиссиям между двумя владельцами канала. Я согласен с мнением ряда разработчиков, что нужно запретить ручное управление этим параметром. Но это моё личное ИМХО.

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

Хорошо бы логи скинуть разработчикам...

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

Мне показалось более красивым - настроить NFS на удаленном сервере (в облаке например) и подключить NFS storage к нашей ноде, как директорию в файловой системе. В linux такая директория ничем не отличается от локальной. Далее я прописал путь к файлу бекапов в эту директорию и вуаля - lnd поддерживает актуальным бекап уже на удаленном сервере и без всяких костылей по копированию файлов.
Я это реализовал на сервисе aws.amazon, на первый взгляд все работает нормально.

Проблема проявилась, когда канал был открыт onchain транзакцией с маленьким fee и сама транзакция висела часов 12 в mempool пока не была добавлена в blockchain. По какой-то причине lnd упустил этот момент и она у меня так и висела в pending. пока я не перезапустил службу lnd.

У меня месяцами LND работает без перезапуска, никогда такой проблемы не было.

Это в общих чертах суть проблемы: https://ru.scribd.com/document/431290943/DoS-attack-on-Lightning#from_embed
Я описал один из возможных вариантов использования этой уязвимости (не буду выкладывать ссылку на него, т.к. это личная переписка с разработчиками).
С одной стороны, маршрут можно задавать как хочется. С Другой стороны, реальная блокировка каналов для совершения платежа выполняется последовательно. И если один из каналов не удаётся заблокировать, текущие реализации автоматически не строят новый маршрут целиком, т.к. это будет связано с отменой предыдущих блокировок. Решение этого вопроса активно прорабатывается, и в ближайших обновлениях описанный вариант будет пофиксен.

Вот решение по авто-бэкапам для LND: https://github.com/darwin/lnd-auto-backup