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

Еще важный момент, говоря про обычное материальное имущество, с завещанием можно не заморачиваться, если вас устраивает распределение имущества по умолчанию, предусмотренное законом. Если мы говорим про крипту, то тут такая схема не работает и по идее КАЖДЫЙ владелец крипты должен иметь какую-то схему ее передачи наследникам, если он не хочет, чтобы она пропала после его смерти.
Интересно, какой процент людей умирает неожиданно/внезапно в современном обществе?

У меня тоже так, если один процесс lnd запустить, а если 16, то у них башню рвет
Есть еще один момент, который мне не нравится в lnd - это потребление памяти, 400Мб - это, извините меня, совсем не мало.

Форумчане с английского раздела посоветовали поставить c-lightning, я уже начал с ним разбираться, сразу пришлось перейти с CentOS 7 на 8-ю версию, т.к. c-lightning требует glibc более новой версии, чем есть в 7-ке.

Ну наконец-то - один здравый человек. Тут все чуть ли не нормой считают поставить наследников в известность, о том, что вы оставляете им наследство.

Хотелось бы, чтобы тот кто предлагает варианты, сам себя ставил на место наследодателя, т.е. примерил на себя предлагаемый метод и задал себе два вопроса:
1. А буду ли я это делать, подходит ли это лично мне?
2. Если мне это подходит, почему я это уже не сделал, чего я тяну?

Thanks guys! I will give c-lightning a shot.

You are damn right! 400Mb of RAM is a lot for a single lnd process with no channels at all.

Tell me about c-lightning service, how reliable and stable it is? How much memory does it need?

PS I have spent so much time on lnd, automation, scripting and so on, and now I came across the bug that pushes me to use something else.

Hi, I have been working on a project where I need to run lots of lnd services on a single machine (physical or virtual, does not matter). In theory, it seems easy, I created a directory structure for each node with its own conf file, tcp ports and so on. It was not difficult and I started 16 nodes for a test on a single VM machine. (CentOS 7)
After starting them, each node begins to update network graph (file channel.db in /data/graph/mainnet); this process is quite long and CPU consuming. After the graph is updated, an lnd service is supposed to go into idle mode with low cpu usage. In reality, this happens but not for a long time. At first, CPU usage stays low but only for a couple of hours, then all services one by one started loading CPU heavily with no reason. The lnd services will not stop doing that until I restart them, then everything happens all over again. One interesting thing is that the bitcoind service does not use almost any CPU resourses; it means that lnd services do not use bitcoind, when they load CPU. I could not find anything unusual in the lnd logs, everything seems normal.
I don't understand what's going on and ho to fix it. My host's hardware should be enought for the purpose (Core i3-3.8Ghz/16Gb RAM/SSD) Maybe somenody has already come accross with this issue. I fould the similar issue on the lnd's github page but there is no solution there.
https://github.com/lightningnetwork/lnd/issues/3370
I am interested to listen to everyone who has any thoughts about it or solutions how to fix it.

Приветствую!
Я работаю над проектом, где мне надо запустить большое количество 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
Мне интересно послушать каждого, у кого есть мысли по поводу, что это и как можно пофиксить.

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

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

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

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

О спасибо! Нашел я там свою ноду, видно с кем открыт канал, правда не видно на сколько он сбалансирован.


Ага получилось, единственное как-то странно цифры отобразились в транзакции. Я указал 3sat/bite, а когда транзакцию провел, получилось 1.8sat/bite. В общем непонятно. Думаю еще открыть пару "двусторонних" каналов с крупными нодами и потестить, как деньги ходят во все стороны.

Кстати, что интересно, тот первый канал от LNBIG ко мне, так и висел в pending, хотя транзакция уже прошла на след. день, я перезапустил LND и она обновила информацию, канал стал рабочий. Короче LND не обновляет информацию о каналах, почему-то.

Продолжаю свою историю настройки ноды.
Решил, что нет смысла открывать односторонние каналы, пока не открою толстые двусторонние. Запросил у LNBIG канал, следуя инструкции все сделал. Канал появился в pending. Сначала ждал спокойно, часов через пять стал гуглить почему канал в pending еще висит. Оказалось подтверждений по транзакции нет, т.е. она висит в мемпуле. Посмотрел какие fee заплатил LNBIG, чтобы этот канал открыть оказалось 1.1sat/b, что как я понимаю мало, чтобы транзакция прошла оперативно. В долларовом эквиваленте LNBIG потратила 2.6 цента на открытие канала.

У меня вопрос, я когда буду открывать канал, как я могу указать fee на on-chain транзакцию, где это настраивается?

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

Я бы хотел знать:
1. Время работы ноды, сколько процентов времени нода онлайн.
2. Сколько каналов открыто у ноды
3. Сколько денег в каналах
4. На сколько каналы сбалансированы (распределение денег в каналах для проведения входящих/сходящих платежей)
5. Сумма проходящих транзитных биткоинов через ноду

Это реально вообще собрать из открытых источников? Или я размечтался

А что за виртуальная машина в вашем интерпретации? О каких оракулах идет речь?

А где будет храниться конверт? Если у наследника, то это надо к нему ездить (а если это другой город/страна?). Если у наследодателя, то нужно держать наследника в курсе о месте хранения, напоминать как-то. Плюс сам наследник должен не потерять/скомпрометировать ключи от своего кошелька в течении долгого времени.

А потом (через 20 лет) окажется, что наследник забыл пароль или его аккаунт стерли за-за неиспользования и все.

Мне такой способ не нравится по нескольким причинам:
0. Лично я не хочу обсуждать вопросы наследства с наследниками, тут нужно будет это делать регулярно. (лично моя заморочка).
1. Способ требует крипто квалификации обеих сторон (наследодателя и наследника)
2. Способ требует регулярной передачи новой транзакции, как время будет подходить. Причем я так понимаю, нужно будет пересоздавать кошелек, чтобы наследник не мог запустить транзакцию раньше смерти наследодателя.
3. Транзакция подразумевает конкретную сумму, но сумма в кошельке потенциального наследодателя может расти или уменьшаться, получается после каждого изменения баланса, нужно пересоздавать транзакцию и давать ее наследнику?

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

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

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

I thought about it, I really did, but

lnd.conf

[neutrino]
; Connect only to the specified peers at startup. This creates a persistent
; connection to a target peer. This is recommended as there aren't many
; neutrino compliant full nodes on the test network yet.
; neutrino.connect=


So, LND needs a full node and I can specify the only one of them. What happens to my LND node if that neutrino node stops working? It would be much more convenient if I did not need to specify a node. I wish it could find a compliant full node on the network itself and connect to it. Like torrent clients do.

One more question about tor nodes. I often see in logs that my node fails to connect to nodes with tor addresses (*.onion). Do I need to choose between Tor and the regular Internet or I can install tor and connect to both of them?

I'm sorry, what is DLP?

You did not get the idea; let me clarify.
I mounted a remote directory to my local directory /mnt/nfsstorage. So, everything I put in there ends up on my NFS server (in amazon cloud). Then I added the backup file path in the lnd.conf file (backupfilepath=/mnt/nfsstorage/lndbackup/channel.backup). The lnd service keeps channel.backup updated constantly. Thus, I do not need to copy anything; the backup file will be updated by lnd directly on the cloud server.

The only problem I might have is with connection to the cloud server. However, the NFS protocol allows to automatically reconnect to a server if the previous connection was interrupted (that's what manual says .
I installed the NFS server yesterday, It seems to be working fine.

PS I would have gladly put everything on a cloud if I had not needed to store the entire blockchain there. Keeping 300Gb on a cloud server is quite expensive.

Thanks for the answer with the explanation!
I googled about possibilities to organize an offchain backup. The developers say:

After version v0.6-beta of lnd, the daemon now ships with a new feature called Static Channel Backups (SCBs). We call these static as they only need to be obtained once: when the channel is created. From there on, a backup is good until the channel is closed. The backup contains all the information we need to initiate the Data Loss Protection (DLP) feature in the protocol, which ultimately leads to us recovering the funds from the channel on-chain. This is a foolproof safe backup mechanism.

We say safe, as care has been taken to ensure that there are no foot guns in this method of backing up channels, vs doing things like rsyncing or copying the channel.db file periodically. Those methods can be dangerous as one never knows if they have the latest state of a channel or not. Instead, we aim to provide a simple, safe method to allow users to recover the settled funds in their channels in the case of partial or complete data loss. The backups themselves are encrypted using a key derived from the user's seed, this way we protect privacy of the users channels in the back up state, and ensure that a random node can't attempt to import another user's channels.

Thus, we can assume that the backup file has always actual data about our channels. So, we just need to put it in a safe place. I am thinking of setting up an NFS server somewhere in a cloud. That way I can mount a remote directory on my LND node and backup the offchain data to it.
What do you think about this solution?

Hi everybody, I set up a lightning node (CentOS + bitcoind + lnd + some scripts) and I have some question about configuring LND.
1. The port, which LND uses to listen to incoming connection is 9735. Is it tcp only port or tcp + udp?
2. The same question about watchtowers' port (9911)
3. How to securely backup offchain data? If something goes wrong with my node's software or hardware, how can I make sure if I have actual offchain data? I know that I will be punished for using outdated data even if I don't mean it. I found the channel.backup file but it's stored localy, what would I do if my ssd died?
4. I read about the watchtowers client, that it is supposed to "connect to backup encrypted justice transactions". I don't know what justice transactions are. Are they my offchain data or they are something else? Is watchtowers client help me to backup offchain data?