Bitcoin Forum
November 18, 2019, 01:25:18 PM *
News: Latest Bitcoin Core release: 0.18.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 [60] 61 »
  Print  
Author Topic: Lightning Network  (Read 38493 times)
QWeB
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
October 26, 2019, 07:31:11 PM
 #1181

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

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

Full LN node LENINGRAD[LND]: 0338f87cb05016c9427de7872192615f9313d622db1a88f6c2594625ffd0b2d270@146.120.67.44:9735

https://tippin.me/@LeningradLnd
1574083518
Hero Member
*
Offline Offline

Posts: 1574083518

View Profile Personal Message (Offline)

Ignore
1574083518
Reply with quote  #2

1574083518
Report to moderator
1574083518
Hero Member
*
Offline Offline

Posts: 1574083518

View Profile Personal Message (Offline)

Ignore
1574083518
Reply with quote  #2

1574083518
Report to moderator
1574083518
Hero Member
*
Offline Offline

Posts: 1574083518

View Profile Personal Message (Offline)

Ignore
1574083518
Reply with quote  #2

1574083518
Report to moderator
The Bitcoin Forum is turning 10 years old! Join the community in sharing and exploring the notable posts made over the years.
1574083518
Hero Member
*
Offline Offline

Posts: 1574083518

View Profile Personal Message (Offline)

Ignore
1574083518
Reply with quote  #2

1574083518
Report to moderator
1574083518
Hero Member
*
Offline Offline

Posts: 1574083518

View Profile Personal Message (Offline)

Ignore
1574083518
Reply with quote  #2

1574083518
Report to moderator
samuel-sd
Member
**
Offline Offline

Activity: 70
Merit: 45


View Profile
October 26, 2019, 11:07:16 PM
 #1182

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

Activity: 378
Merit: 250



View Profile
October 28, 2019, 07:51:14 AM
 #1183

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

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

Full LN node LENINGRAD[LND]: 0338f87cb05016c9427de7872192615f9313d622db1a88f6c2594625ffd0b2d270@146.120.67.44:9735

https://tippin.me/@LeningradLnd
UnholyLizard
Full Member
***
Offline Offline

Activity: 336
Merit: 152


BitcoinTrollzUnite


View Profile WWW
October 28, 2019, 10:38:12 AM
 #1184

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

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

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

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

"Игра" в биток против фиата - игра с ненулевой суммой - ибо дефляционный актив против инфляционного (нет, говнокоины - это лотерея). Требуется некое количество постоянных игроков желающих "играть" продолжительное время. За 9 лет очевидно такие "игроки" уже есть, и уходить не спешат, скорее наоборот (единичные Роджеры не в счет - один ушел, другой пришел). Теория игр про игры с ненулевой суммой в общественном разрезе с моделированием "выигрышной" стратегии поведения
QWeB
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
October 28, 2019, 06:45:01 PM
Last edit: October 30, 2019, 04:54:49 AM by QWeB
Merited by chimk (5), leonello (1)
 #1185

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

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

Full LN node LENINGRAD[LND]: 0338f87cb05016c9427de7872192615f9313d622db1a88f6c2594625ffd0b2d270@146.120.67.44:9735

https://tippin.me/@LeningradLnd
UnholyLizard
Full Member
***
Offline Offline

Activity: 336
Merit: 152


BitcoinTrollzUnite


View Profile WWW
October 29, 2019, 06:41:36 PM
Merited by chimk (4), QWeB (1)
 #1186

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 транзы).

"Игра" в биток против фиата - игра с ненулевой суммой - ибо дефляционный актив против инфляционного (нет, говнокоины - это лотерея). Требуется некое количество постоянных игроков желающих "играть" продолжительное время. За 9 лет очевидно такие "игроки" уже есть, и уходить не спешат, скорее наоборот (единичные Роджеры не в счет - один ушел, другой пришел). Теория игр про игры с ненулевой суммой в общественном разрезе с моделированием "выигрышной" стратегии поведения
GGUL
Legendary
*
Offline Offline

Activity: 1278
Merit: 1038


View Profile
November 01, 2019, 01:18:19 PM
Last edit: November 01, 2019, 02:20:43 PM by GGUL
Merited by KTChampions (1)
 #1187

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

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

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

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

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

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

Activity: 378
Merit: 250



View Profile
November 01, 2019, 02:41:18 PM
 #1188

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

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

Full LN node LENINGRAD[LND]: 0338f87cb05016c9427de7872192615f9313d622db1a88f6c2594625ffd0b2d270@146.120.67.44:9735

https://tippin.me/@LeningradLnd
GGUL
Legendary
*
Offline Offline

Activity: 1278
Merit: 1038


View Profile
November 01, 2019, 02:56:10 PM
 #1189

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

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

Activity: 378
Merit: 250



View Profile
November 01, 2019, 03:00:20 PM
 #1190

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

Full LN node LENINGRAD[LND]: 0338f87cb05016c9427de7872192615f9313d622db1a88f6c2594625ffd0b2d270@146.120.67.44:9735

https://tippin.me/@LeningradLnd
GGUL
Legendary
*
Offline Offline

Activity: 1278
Merit: 1038


View Profile
November 01, 2019, 08:22:08 PM
 #1191

Многомаршрутные - это когда сумма разбивается на части и каждая часть отправляется своим маршрутом?
К сожалению, в этом случае вероятность того, что в целом платеж будет успешным, будет только уменьшаться. Smiley
Я думаю, что этот механизм позволит выявить "проходные" маршруты и прогнать остатки суммы через них.
То есть, планируете разбивать суммы платежа на несколько частей и пропускать через разные маршруты, при этом размер суммы для маршрута будет заведомо меньше, чем этот маршрут позволяет? Зачем эти танцы с бубнами? Smiley
QWeB
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
November 02, 2019, 07:41:02 AM
 #1192

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

Full LN node LENINGRAD[LND]: 0338f87cb05016c9427de7872192615f9313d622db1a88f6c2594625ffd0b2d270@146.120.67.44:9735

https://tippin.me/@LeningradLnd
GGUL
Legendary
*
Offline Offline

Activity: 1278
Merit: 1038


View Profile
November 02, 2019, 09:34:32 AM
 #1193

Зачем эти танцы с бубнами? Smiley
Вродеб, выше было обозначено зачем? Чтобы противодействовать злонамеренной блокировке каналов. Об этом же говорим?
Зачем отправлять сумму меньше, чем позволяет маршрут? Мне кажется, с таким же успехом можно пытаться отправлять ровно столько, сколько позволяет маршрут. Если не получится, то создавать другой и пытаться отправлять по ней. И так до победного конца.
QWeB
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
November 02, 2019, 01:38:55 PM
 #1194

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

Full LN node LENINGRAD[LND]: 0338f87cb05016c9427de7872192615f9313d622db1a88f6c2594625ffd0b2d270@146.120.67.44:9735

https://tippin.me/@LeningradLnd
GGUL
Legendary
*
Offline Offline

Activity: 1278
Merit: 1038


View Profile
November 02, 2019, 02:03:21 PM
 #1195

И так до победного конца.
Поздравляю! Сейчас так и работает.
Тогда почему Ваш вариант c отправкой мелкими суммами по разным маршрутам будет лучше? Smiley
QWeB
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250



View Profile
November 03, 2019, 11:41:20 AM
 #1196

Тогда почему Ваш вариант c отправкой мелкими суммами по разным маршрутам будет лучше? Smiley
Он не мой. И лучше для каких целей?

Full LN node LENINGRAD[LND]: 0338f87cb05016c9427de7872192615f9313d622db1a88f6c2594625ffd0b2d270@146.120.67.44:9735

https://tippin.me/@LeningradLnd
samuel-sd
Member
**
Offline Offline

Activity: 70
Merit: 45


View Profile
November 04, 2019, 06:36:45 PM
 #1197

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

Activity: 378
Merit: 250



View Profile
November 04, 2019, 08:45:55 PM
 #1198

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

Full LN node LENINGRAD[LND]: 0338f87cb05016c9427de7872192615f9313d622db1a88f6c2594625ffd0b2d270@146.120.67.44:9735

https://tippin.me/@LeningradLnd
samuel-sd
Member
**
Offline Offline

Activity: 70
Merit: 45


View Profile
November 05, 2019, 05:08:08 AM
 #1199

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

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

Activity: 378
Merit: 250



View Profile
November 05, 2019, 06:56:06 AM
 #1200

Форумчане с английского раздела посоветовали поставить c-lightning, я уже начал с ним разбираться, сразу пришлось перейти с CentOS 7 на 8-ю версию, т.к. c-lightning требует glibc более новой версии, чем есть в 7-ке.
У меня была c-lightning. Основная причина, по которой я сменил движок это постоянные самопроизвольные закрытия каналов (год назад). Возможно это сейчас уже изменилось.
+ не поддерживает несколько каналов на одно соединение, т.е. например, нельзя сделать два разнонаправленных канала между двумя нодами.

Я ещё пробовал eclair на андройде, там не всегда проходили платежи, но сейчас всё вроде бы ОК у них.

Full LN node LENINGRAD[LND]: 0338f87cb05016c9427de7872192615f9313d622db1a88f6c2594625ffd0b2d270@146.120.67.44:9735

https://tippin.me/@LeningradLnd
Pages: « 1 ... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 [60] 61 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!