|
QWeB
|
 |
October 28, 2019, 07:51:14 AM |
|
Подскажите, а для unchain транзакции на закрытие канала, тоже можно выгодное указать fee? Если так, то можно очень снизить onchain расходы, по сравнению например с обычным покупателем, который хочет купить что-то здесь и сейчас, а мемпул забит.
В своё время было много падений каналов, связанных с отсутствием консенсуса по этим комиссиям между двумя владельцами канала. Я согласен с мнением ряда разработчиков, что нужно запретить ручное управление этим параметром. Но это моё личное ИМХО. |
|
|
|
|
|
|
|
|
"I'm sure that in 20 years there will either be very large transaction volume or no volume." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
UnholyLizard
Full Member
 Offline
Activity: 336
Merit: 160
BitcoinTrollzUnite
|
|
October 28, 2019, 10:38:12 AM |
|
Попался на глаза тест Watchtowers (тестнет) с подробным гайдом для желающих повторить https://random.engen.priv.no/archives/635Подскажите, а для unchain транзакции на закрытие канала, тоже можно выгодное указать fee? Если так, то можно очень снизить onchain расходы, по сравнению например с обычным покупателем, который хочет купить что-то здесь и сейчас, а мемпул забит.
В своё время было много падений каналов, связанных с отсутствием консенсуса по этим комиссиям между двумя владельцами канала. Я согласен с мнением ряда разработчиков, что нужно запретить ручное управление этим параметром. Но это моё личное ИМХО. Ну, для случая когда одна сторона хочет закрыть канал (т.е. канал "упадет" при любом исходе) если обе стороны согласны на некое уменьшение комиссии то почему бы и нет?. Тут вся "сложность" только в том что комиссию платит только одна сторона (тот кто открывал канал) поэтому другой стороне особого стимула к ее снижению нет. |
|
|
|
|
QWeB
|
|
October 28, 2019, 06:45:01 PM
Last edit: October 30, 2019, 04:54:49 AM by QWeB Merited by chimk (5), leonello (1) |
|
Ну, для случая когда одна сторона хочет закрыть канал (т.е. канал "упадет" при любом исходе) если обе стороны согласны на некое уменьшение комиссии то почему бы и нет?. Тут вся "сложность" только в том что комиссию платит только одна сторона (тот кто открывал канал) поэтому другой стороне особого стимула к ее снижению нет.
Когда имплементация одного разработчика LN (например, c-lightning) с одной стороны автоматически устанавливала комиссии ниже диапазона возможных комиссий имплементации от другого разработчика LN (например, eclair) на другой стороне канала, это приводило к ошибке и автоматическому закрытию канала. Под "падением" подразумевается автоматическое закрытие канала вопреки воли тех, кто его создал, сугубо по техническим причинам. Тут вся "сложность" только в том что комиссию платит только одна сторона (тот кто открывал канал) поэтому другой стороне особого стимула к ее снижению нет.
Так-то комиссию нужно платить три раза за жизненный цикл канала (или два при кооперативном закрытии канала): при создании канала, при блокировке средств на смарт контракте, при возврате средств на свой кошелёк. Закрытие канала может инициировать любая из сторон, даже если вторая сторона не алё не он-лайн. |
|
|
|
UnholyLizard
Full Member
Offline
Activity: 336
Merit: 160
BitcoinTrollzUnite
|
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 транзы).
|
|
|
|
GGUL
Legendary
Offline
Activity: 1468
Merit: 1102
|
|
November 01, 2019, 01:18:19 PM
Last edit: November 01, 2019, 02:20:43 PM by GGUL Merited by KTChampions (1) |
|
Можно ссылку на оригинал? В теории тут контроль полностью у клиента отправителя - клиент генерирует маршрут (рандомный или заданный), пытается провести оплату по этому маршруту (максимальный размер комиссии который клиент готов оплатить тоже можно задать), если оплатить по данному маршруту не удается - строится новый маршрут, и т.д. Если какая-то нода будет говорить что по маршруту проходящему через нее "канал не доступен" то она может быть занесена клиентом в "черный список". Установленные каналом комиссии это публичная инфа, не в курсе на сколько возможно пытаться менять ее "на лету" но в любом случае думаю в будущем клиенты будут вести свой внутренний рейтинг каналов, нерешаемых проблем тут не вижу.
Насколько я понимаю, канал может быть недоступен и по уважительным причинам. И у отправителя нет возможности распознавать, была ли уважительная причина или нет. Занесение ноды в "черный список" при каждом таком случае не выглядит таким уж хорошим решением. Так всю сеть можно "зачернить".  С одной стороны, маршрут можно задавать как хочется. С Другой стороны, реальная блокировка каналов для совершения платежа выполняется последовательно. И если один из каналов не удаётся заблокировать, текущие реализации автоматически не строят новый маршрут целиком, т.к. это будет связано с отменой предыдущих блокировок. Решение этого вопроса активно прорабатывается, и в ближайших обновлениях описанный вариант будет пофиксен.
Фиксят обычно ошибки. В данном случае был реализован определенный алгоритм построения маршрута. И он был выбран таким исходя из каких-то благих соображений. Чтобы пофиксить, необходимо придумать другой алгоритм. А где гарантия, что у нового алгоритма не будет своих слабостей и уязвимостей? Например, решим, что маршрут в таком случае будет строиться по новой. Тогда необходимо отменить все уже сделанные блокировки каналов. А это время, потраченное каналами впустую. На ум сразу приходит злоумышленник, который строит маршрут, запускает его, блокирует N каналов, на N+1 канале отменяет, при этом выждав максимальную паузу. И в бесконечном цикле. И ноды ничего не могут сделать, ведь они не знают, кто запускает маршрут. Чисто теоретически. Как построить надежную децентрализованную систему? Ведь в качестве аксиомы надо принять, что часть участников системы будут вести себя злонамеренно/деструктивно. Первое, что приходит в голову, это распараллеливание действий. Запускаешь N процессов, если даже несколько из них попадут на деструктивного участника, то ничего страшного не произойдет, остальные сработают. Так, как это устроено в блокчейне. Связываешься с 10 участниками, делаешь транзакцию и кидаешь всем. Или же майнеры, которые работают параллельно, а не последовательно. Если, например, 10% узлов в Биткоине будут злоумышленниками. Тогда при подключении к 10 случайным нодам вероятность того, что не получится отправить транзакцию, составляет 0.1^10. То есть, практически, ноль. А если же возьмем LN, у которого 10% процентов узлов злоумышленники. Тогда, при длине маршрута 5, вероятность того, что попадете на злоумышленника равна около 1/2. То есть, при одинаковых начальных условиях, насколько огромная разница между этими системами. И становится понятно, насколько трудно будет реализовать бесперебойную и надежную работу в LN. |
|
|
|
|
|
QWeB
|
|
November 01, 2019, 02:41:18 PM |
|
Фиксят обычно ошибки. Ну да. Я и имел ввиду конкретную проблему, которую описал выше: когда есть канал магнит и есть остальные каналы с мега-комиссией. Но это не решение всего "пучка" возможных проблем. Раз уж у нас тут назревает обсуждение, то я в качестве вброса предположу, что остроту проблемы снимут многомаршрутные платежи. |
|
|
|
GGUL
Legendary
Offline
Activity: 1468
Merit: 1102
|
|
November 01, 2019, 02:56:10 PM |
|
Фиксят обычно ошибки. Ну да. Я и имел ввиду конкретную проблему, которую описал выше: когда есть канал магнит и есть остальные каналы с мега-комиссией. Но это не решение всего "пучка" возможных проблем. Раз уж у нас тут назревает обсуждение, то я в качестве вброса предположу, что остроту проблемы снимут многомаршрутные платежи. Многомаршрутные - это когда сумма разбивается на части и каждая часть отправляется своим маршрутом? К сожалению, в этом случае вероятность того, что в целом платеж будет успешным, будет только уменьшаться. |
|
|
|
|
|
QWeB
|
|
November 01, 2019, 03:00:20 PM |
|
Многомаршрутные - это когда сумма разбивается на части и каждая часть отправляется своим маршрутом? К сожалению, в этом случае вероятность того, что в целом платеж будет успешным, будет только уменьшаться. Я думаю, что этот механизм позволит выявить "проходные" маршруты и прогнать остатки суммы через них. |
|
|
|
GGUL
Legendary
Offline
Activity: 1468
Merit: 1102
|
|
November 01, 2019, 08:22:08 PM |
|
Многомаршрутные - это когда сумма разбивается на части и каждая часть отправляется своим маршрутом? К сожалению, в этом случае вероятность того, что в целом платеж будет успешным, будет только уменьшаться. Я думаю, что этот механизм позволит выявить "проходные" маршруты и прогнать остатки суммы через них. То есть, планируете разбивать суммы платежа на несколько частей и пропускать через разные маршруты, при этом размер суммы для маршрута будет заведомо меньше, чем этот маршрут позволяет? Зачем эти танцы с бубнами? |
|
|
|
|
|
QWeB
|
|
November 02, 2019, 07:41:02 AM |
|
Зачем эти танцы с бубнами? Вродеб, выше было обозначено зачем? Чтобы противодействовать злонамеренной блокировке каналов. Об этом же говорим? |
|
|
|
GGUL
Legendary
Offline
Activity: 1468
Merit: 1102
|
|
November 02, 2019, 09:34:32 AM |
|
Зачем эти танцы с бубнами? Вродеб, выше было обозначено зачем? Чтобы противодействовать злонамеренной блокировке каналов. Об этом же говорим? Зачем отправлять сумму меньше, чем позволяет маршрут? Мне кажется, с таким же успехом можно пытаться отправлять ровно столько, сколько позволяет маршрут. Если не получится, то создавать другой и пытаться отправлять по ней. И так до победного конца. |
|
|
|
|
|
QWeB
|
|
November 02, 2019, 01:38:55 PM |
|
И так до победного конца.
Поздравляю! Сейчас так и работает. |
|
|
|
GGUL
Legendary
Offline
Activity: 1468
Merit: 1102
|
|
November 02, 2019, 02:03:21 PM |
|
И так до победного конца.
Поздравляю! Сейчас так и работает. Тогда почему Ваш вариант c отправкой мелкими суммами по разным маршрутам будет лучше? |
|
|
|
|
|
QWeB
|
|
November 03, 2019, 11:41:20 AM |
|
Тогда почему Ваш вариант c отправкой мелкими суммами по разным маршрутам будет лучше? Он не мой. И лучше для каких целей? |
|
|
|
samuel-sd
Member
Offline
Activity: 155
Merit: 67
|
|
November 04, 2019, 06:36:45 PM |
|
Приветствую! Я работаю над проектом, где мне надо запустить большое количество 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
|
|
November 04, 2019, 08:45:55 PM |
|
Мне интересно послушать каждого, у кого есть мысли по поводу, что это и как можно пофиксить.
У меня htop показывает загрузку 2%, при этом bitcoind на первом месте, lnd на втором. Ubuntu, LND 0.8.0. Мыслей нет. |
|
|
|
samuel-sd
Member
Offline
Activity: 155
Merit: 67
|
|
November 05, 2019, 05:08:08 AM |
|
У меня htop показывает загрузку 2%, при этом bitcoind на первом месте, lnd на втором. Ubuntu, LND 0.8.0. Мыслей нет.
У меня тоже так, если один процесс lnd запустить, а если 16, то у них башню рвет Есть еще один момент, который мне не нравится в lnd - это потребление памяти, 400Мб - это, извините меня, совсем не мало. Форумчане с английского раздела посоветовали поставить c-lightning, я уже начал с ним разбираться, сразу пришлось перейти с CentOS 7 на 8-ю версию, т.к. c-lightning требует glibc более новой версии, чем есть в 7-ке. |
|
|
|
|
|
QWeB
|
|
November 05, 2019, 06:56:06 AM |
|
Форумчане с английского раздела посоветовали поставить c-lightning, я уже начал с ним разбираться, сразу пришлось перейти с CentOS 7 на 8-ю версию, т.к. c-lightning требует glibc более новой версии, чем есть в 7-ке.
У меня была c-lightning. Основная причина, по которой я сменил движок это постоянные самопроизвольные закрытия каналов (год назад). Возможно это сейчас уже изменилось. + не поддерживает несколько каналов на одно соединение, т.е. например, нельзя сделать два разнонаправленных канала между двумя нодами. Я ещё пробовал eclair на андройде, там не всегда проходили платежи, но сейчас всё вроде бы ОК у них. |
|
|
|
samuel-sd
Member
Offline
Activity: 155
Merit: 67
|
|
November 05, 2019, 06:34:42 PM |
|
У меня была c-lightning. Основная причина, по которой я сменил движок это постоянные самопроизвольные закрытия каналов (год назад). Возможно это сейчас уже изменилось.
Надо c-lightning потестить. Сейчас с ним ковыряюсь, я не понял, ему нужен прямой доступ к bitcoind (доступ к файлам) или c-lightning может по сети все брать, что нужно с bitcoind сервиса. Я в конфиге c-lightning нахожу какие-то опции путей к bitcoind, это зачем? bitcoin-cli=PATH The name of bitcoin-cli executable to run.
bitcoin-datadir=DIR -datadir argument to supply to bitcoin-cli(1). |
|
|
|
|
samuel-sd
Member
Offline
Activity: 155
Merit: 67
|
|
November 06, 2019, 04:25:28 AM |
|
Еще общий вопрос возник по lightning.
По моей задумке у меня есть:
- одна основная "нода-хаб", у которой открыты каналы к другим, сторонним нодам сети.
- много "нод-поинтов", которые имеют только один канал к ноде-хабу, больше ни с кем они каналов не будут открывать.
Т.е. все платежи должны проходить через ноду-хаб. Если я открою каналы через локальные интерфейсы нод (192.168.1.*) это ведь ничего?
Входящие платежи будут проходить из вне на ноды-поинты? Нодам-поинтам же не надо advertise себя в общей сети?
Если нода-хаб будет иметь с ними открытые каналы, то она уже и передаст остальным, что мол все платежи заруливайте на меня?
Я правильно понял принцип?
|
|
|
|
|
|
