Lightning Network

[QWeB]

...Вопрос у меня такой: поиск маршрута от Васи до Ларька идет по схожему сценарию? Или придумали что-то поинтересней?

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

Единственное новшество LN, что можно пересылать ценность, не доверяя друг-другу (в разумных границах).

[A-Bolt]

1. Если Вася планирует через канал покупать пиво целый год, то он сразу должен вложить в канал годовую сумму. Другими словами, найти свободные(лишние) деньги и авансом заплатить за целый год. Кто так делает? 

Никто не запрещает Васе открыть канал на квартальную сумму, если годовую не осилит.

2. Зачем Ларьку открывать канал с Васей? Ведь, теми средствами, которые Ларек будет получать через канал от Васи в течение года, Ларек сможет воспользоваться только тогда, когда закроется канал. То есть, весь год Ларек будет поить Васю за свой счет, в кредит.

Любая сторона может в любой момент закрыть канал и высвободить средства в нём хранящиеся.

Вам не кажется, что концепция платежных каналов очень далека от жизненных реалий?

Это немного неудобно: открывать каналы к каждому ларьку где я что-то планирую покупать в этом году. Да и ларьки не сильно обрадуются поддерживать открытые каналы со всеми своими покупателями.
Тут выше совершенно верно подметили, как это должно работать с точки зрения удобства:
1. загрузил софтину
2. открыл один канал
3. идешь в любой магазин за покупками.

Разработчики LN поставили перед собой задачу: использование криптовалют для платежей:
массовых (по числу транзакций в секунду),
быстрых (не ждать пока транзакцию включат в блок),
не требующих посредников, которым нужно доверять.
И они эту задачу решили.

Никто не ставил задачу сделать всё это ещё и удобным. Хотите удобств - пользуйтесь криптовалютами без надстроек: выплюнул транзакцию безо всяких предварительных ласк в виде открытия канала, а там хоть трава не расти, и не важно: в онлайне получатель или нет. Но придётся ждать, как минимум, включения транзакции в блок, как максимум - 6 подтверждений. 

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

[QWeB]

Вообще-то, интересная эта вся затея с биткоином и лайтнингом с экономической точки зрения (кейнсианской модели).

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

В биткоине, мало того, что дефляция (в перспективе), так ещё и для совершения лайтнинг-платежей денежная масса "морозится" в каналах (а не увеличивается, как в банковской среде).

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

[kzv]

...Вопрос у меня такой: поиск маршрута от Васи до Ларька идет по схожему сценарию? Или придумали что-то поинтересней?

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

То есть если теймос решит купить кокосовой стружки и не позаботится заранее о прямом канале с пабло эскобаро, то через пару секунд о сделке теймоса узнает вся сеть LN c реальными ип адресами сторон в качестве бонуса? Что-то мне подсказывает, что классический биткоин будет пользоваться значительно большей популярностью для подобных сделок.

Разработчики LN поставили перед собой задачу: использование криптовалют для платежей:
массовых (по числу транзакций в секунду),
быстрых (не ждать пока транзакцию включат в блок),
не требующих посредников, которым нужно доверять.
И они эту задачу решили.

Никто не ставил задачу сделать всё это ещё и удобным.

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

Я тоже могу сказать: разработчики Лады Калины поставили перед собой задачу сделать автомобиль который разгоняется до сотки за две секунды. И они эту задачу решили!.. Правда она сейчас пока разгоняется за 20 секунд, но когда Калину начнут покупать арабские шейхи своим женам, то к крыше прикрутят гиперзвуковую ракету и тогда главное чтобы саморезы выдержали...

[amaclin1]

Тут есть 2 нюанса.
1. Если Вася планирует через канал покупать пиво целый год, то он сразу должен вложить в канал годовую сумму. Другими словами, найти свободные(лишние) деньги и авансом заплатить за целый год. Кто так делает?  

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

2. Зачем Ларьку открывать канал с Васей? Ведь, теми средствами, которые Ларек будет получать через канал от Васи в течение года, Ларек сможет воспользоваться только тогда, когда закроется канал. То есть, весь год Ларек будет поить Васю за свой счет, в кредит.

Ларьку, ясен плинтус, не нужно открывать каналы на Васю. Ларьку надо открывать каналы на поставщиков.
А лучше всего на некий "банк" - ноду с большой связностью.

Вам не кажется, что концепция платежных каналов очень далека от жизненных реалий?

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

[QWeB]

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

Это уже обсуждалось многократно. Каждый участник транзакции знает только от кого пришла транзакция и к кому она далее пойдёт. Неизвестно, сколько нод было до, и сколько будет после, кто отправитель и кто получатель. Только отправитель знает весь маршрут.

Например, недавно через мою ноду транзитом прошла транзакция. Вот вся информация, что у меня есть (надеюсь, переводить не нужно?):

Code:

  {
            "timestamp": "1552233536",
            "chan_id_in": "619577002455324672",
            "chan_id_out": "617503563405152257",
            "amt_in": "80001",
            "amt_out": "80000",
            "fee": "1",
            "fee_msat": "1080"
        }

Мне просто даже интересно, на основании чего вы делаете такие (неверные) заключения неоднократно? Можно же прочитать или просто спросить...

[kzv]

Каждый участник транзакции знает только от кого пришла транзакция и к кому она далее пойдёт. Неизвестно, сколько нод было до, и сколько будет после, кто отправитель и кто получатель. Только отправитель знает весь маршрут.

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

[dariloff]

Каждый участник транзакции знает только от кого пришла транзакция и к кому она далее пойдёт. Неизвестно, сколько нод было до, и сколько будет после, кто отправитель и кто получатель. Только отправитель знает весь маршрут.

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

Все исходники открыты, не надо себе подсказывать, просто открывается и смотрится. Экплореры видели LN с картой? Как Вы думаете он сделан? Персональным запросом к каждой отдельной ноде каждые 30 минут? Схема рисуется 1 вызвом describegraph в LND. Это значит только то, что каждая нода имеет представление о сети в памяти. Поэтому маршрут строится явно не опросом всех нод под каждый маршрут, что, даже не углубляясь, звучит крайне неэффективно.

[kzv]

Все исходники открыты, не надо себе подсказывать, просто открывается и смотрится. Экплореры видели LN с картой? Как Вы думаете он сделан? Персональным запросом к каждой отдельной ноде каждые 30 минут? Схема рисуется 1 вызвом describegraph в LND. Это значит только то, что каждая нода имеет представление о сети в памяти. Поэтому маршрут строится явно не опросом всех нод под каждый маршрут, что, даже не углубляясь, звучит крайне неэффективно.

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

Code:

{
            "timestamp": "1552233536",
            "chan_id_in": "619577002455324672",
            "chan_id_out": "617503563405152257",
            "amt_in": "80001",
            "amt_out": "80000",
            "fee": "1",
            "fee_msat": "1080"
        }

Что я тут вижу?
Вижу входящего соседа, исходящего соседа. Я не вижу конечной точки куда это должно в итоге прийти...
Спрашивается: а мой исходящий сосед "chan_id_out" откуда узнает куда дальше это дело отправлять? У него ведь будет в логах что-то типа такого

Code:

{
            "timestamp": "1552233546",
            "chan_id_in": "617503563405152257",
            "chan_id_out": "xxxxxxxx",
            "amt_in": "80000",
            "amt_out": "79999",
            "fee": "1",
            "fee_msat": "1080"
        }

Мне тут все понятно, кроме: откуда взять значение "xxxxxxxx"?

[QWeB]

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

Ссылка на оригинальный текст на английском: https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md
Далее идёт мой личный суверенный и субъективный перевод той части, которая касается маршрутизации:

Code:

Сообщение обновления информации о канале (сплетни).

После того, как канал был первоначально объявлен, каждая сторона независимо объявляет размер комиссии и минимальную дельту истечения срока действия , которая требуется для ретрансляции HTLC (врЕменных блокировок для прохождения платежей) через этот канал. Каждая из сторон использует 8-байтовый короткий идентификатор канала, который соответствует channel_announcement и 1-битному полю channel_flags, чтобы указать, на каком конце канала он находится (в начале или в конце канала). Узел может делать это многократно, чтобы изменять плату за использование канала.

Обратите внимание, что сообщение о "сплетне" channel_update полезно только в контексте ретрансляции платежей нодами, и не нужны для отправки платежей. При совершении платежа A -> B -> C -> D используются только channel_updates (сплетни), относящиеся к каналам B -> C (объявлен B) и C -> D (объявлен C). При построении маршрута, суммы и сроки действия для блокировок каналов (HTLC) должны быть рассчитаны в обратном направлении от пункта назначения к источнику. Точное начальное значение для amount_msat и минимальное значение для cltv_expiry, которое будет использоваться для последней HTLC (блокировке) в маршруте, указаны в запросе на оплату (см. БОЛТ № 11).

    тип: 258 (channel_update)
    данные:
        [64: signature]
        [32: chain_hash]
        [8: short_channel_id]
        [4: временная метка]
        [1: message_flags]
        [1: channel_flags]
        [2: cltv_expiry_delta]
        [8: htlc_minimum_msat]
        [4: fee_base_msat]
        [4: fee_proportional_millionths]
        [8: htlc_maximum_msat] (option_channel_htlc_max)

Битовое поле channel_flags используется для указания направления канала: оно идентифицирует узел, с которого произошло это обновление, и сигнализирует о различных параметрах, касающихся канала. В следующей таблице указано значение отдельных битов:

Позиция            Название          Значение
0                  direction         направление, к которому относится это обновление.
1                  disable           отключить канал.

Битовое поле message_flags используется для указания наличия дополнительных полей в сообщении channel_update:

Позиция бита    Имя                                  Поле
0               option_channel_htlc_max              htlc_maximum_msat

Обратите внимание, что поле htlc_maximum_msat является статическим в текущем протоколе на протяжении всего срока службы канала: оно не предназначено для указания пропускной способности канала в реальном времени в каждом направлении, что может быть как массовой утечкой данных, так и бесполезным спамом в сети ( для распространения каждой сплетни требуется в среднем 30 секунд на один переход)

Node_id для проверки подписи берется из соответствующего channel_announcement: node_id_1, если младший значащий бит флагов равен 0, или node_id_2 в противном случае.

Требования

Исходный узел:

    МОЖЕТ создать channel_update для передачи параметров канала равноправному каналу, даже если канал еще не был объявлен (то есть бит анонса_канала не был установлен).
        НЕ ДОЛЖЕН пересылать такой channel_update другим партнерам по причинам конфиденциальности.
        Примечание: такое channel_update, которому не предшествует channel_announcement, недопустимо для любого другого однорангового узла и будет отброшено.
    ДОЛЖЕН установить подпись для подписи двойного SHA256 всего оставшегося пакета после подписи, используя свой собственный идентификатор_узла.
    НЕОБХОДИМО установить chain_hash AND short_channel_id, чтобы соответствовать 32-байтовому хешу И 8-байтовому идентификатору канала, который однозначно идентифицирует канал, указанный в сообщении channel_announcement.
    если исходный узел является node_id_1 в сообщении:
        ДОЛЖЕН установить бит направления channel_flags в 0.
    иначе:
        ДОЛЖЕН установить бит направления channel_flags в 1.
    если присутствует поле htlc_maximum_msat:
        ДОЛЖЕН установить бит option_channel_htlc_max в message_flags равным 1.
        ДОЛЖЕН установить для htlc_maximum_msat максимальное значение, которое будет отправлено через этот канал для одного HTLC.
            ДОЛЖЕН установить это значение меньше или равно пропускной способности канала.
            ДОЛЖЕН установить это значение меньше или равным max_htlc_value_in_flight_msat, полученному от однорангового узла.
            для каналов с chain_hash, идентифицирующих цепочку биткойнов:
                ДОЛЖЕН установить это значение менее 2 ^ 32.
    иначе:
        ДОЛЖЕН установить бит option_channel_htlc_max в message_flags равным 0.
    ДОЛЖНЫ установить биты в channel_flags и message_flags, которым не присвоено значение 0.
    МОЖЕТ создать и отправить channel_update с битом отключения, установленным в 1, чтобы сигнализировать о временной недоступности канала (например, из-за потери соединения) ИЛИ постоянной недоступности (например, до расчета по цепочке).
        МОЖЕТ послать последующее channel_update с битом отключения, установленным в 0, чтобы повторно включить канал.
    ДОЛЖЕН установить временную метку больше 0, а больше, чем любая ранее отправленная channel_update для этого short_channel_id.
        СЛЕДУЕТ основывать метку времени на метке времени UNIX.
    ДОЛЖЕН установить для cltv_expiry_delta количество блоков, которое будет вычтено из входящего HTLC cltv_expiry.
    ДОЛЖЕН установить для htlc_minimum_msat минимальное значение HTLC (в миллисатосах), которое будет принимать одноранговый канал.
    ДОЛЖЕН установить в fee_base_msat базовую плату (в миллисатоши), которую он будет взимать за любой HTLC.
    ДОЛЖЕН установить fee_proportional_millionths на сумму (в миллионных долях сатоши), которую он будет взимать за каждую переведенную сатоши.
    НЕ ДОЛЖЕН создавать избыточные channel_updates

Принимающий узел:

    если short_channel_id НЕ соответствует предыдущему channel_announcement, ИЛИ, если канал был закрыт в это время:
        НЕОБХОДИМО игнорировать channel_updates, которые НЕ соответствуют одному из его собственных каналов.
    СЛЕДУЕТ принимать channel_updates для своих собственных каналов (даже если они не являются общедоступными), чтобы узнать параметры пересылки связанных исходных узлов.
    если подпись не является действительной подписью, используется node_id двойного SHA256 всего сообщения, следующего за полем подписи (включая неизвестные поля после fee_proportional_millionths):
        НЕ ДОЛЖЕН обрабатывать сообщение дальше.
        ДОЛЖЕН разорвать соединение.
    если указанное значение chain_hash неизвестно (то есть оно не активно в указанной цепочке):
        НЕОБХОДИМО игнорировать обновление канала.
    если отметка времени НЕ больше, чем отметка последнего полученного channel_update для этого short_channel_id И для node_id:
        ДОЛЖЕН игнорировать сообщение.
    иначе:
        если временная метка равна последнему полученному channel_update И поля (кроме подписи) отличаются:
            МОЖЕТ занести в черный список этот node_id.
            МОЖЕТ забыть все каналы, связанные с ним.
    если отметка времени необоснованно далека в будущем:
        МОЖЕТ отказаться от channel_update.
    иначе:
        СЛЕДУЕТ помещать в очередь сообщение для ретрансляции.
        МОЖЕТ выбрать НЕ для сообщений длиннее минимальной ожидаемой длины.
    если бит option_channel_htlc_max для message_flags равен 0:
        ДОЛЖЕН считать, что htlc_maximum_msat не присутствует.
    иначе:
        если htlc_maximum_msat отсутствует или превышает емкость канала:
            МОЖЕТ занести в черный список этот node_id
            СЛЕДУЕТ игнорировать этот канал при рассмотрении маршрута.
        иначе:
            СЛЕДУЕТ учитывать htlc_maximum_msat при маршрутизации.

Обоснование

Поле метки времени используется узлами для упрощения channel_updates, которые либо слишком далеки в будущем, либо не были обновлены в течение двух недель; поэтому имеет смысл, чтобы это была временная метка UNIX (т.е. секунды с UTC 1970-01-01). Это не может быть жестким требованием, учитывая возможный случай двух channel_updates в течение одной секунды.

Явный флаг option_channel_htlc_max, указывающий на наличие htlc_maximum_msat (вместо того, чтобы иметь htlc_maximum_msat, который подразумевает длину сообщения), позволяет нам расширять channel_update различными полями в будущем. Поскольку ширина каналов ограничена 2 ^ 32-1 миллисатосами, htlc_maximum_msat имеет такое же ограничение.

Рекомендация против избыточных channel_updates сводит к минимуму спам в сети, однако иногда это неизбежно. Например, канал с одноранговым узлом, который недоступен, в конечном счете заставит channel_update указать, что канал отключен, с другим обновлением, повторно включающим канал, когда одноранговый узел восстанавливает контакт. Поскольку сообщения о сплетнях группируются и заменяют предыдущие, результатом может быть одно, казалось бы, избыточное обновление.

[QWeB]

Мне тут все понятно, кроме: откуда взять значение "xxxxxxxx"?

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

[kzv]

По ссылке написано

Channel discovery allows the creation and maintenance of a local view of the network's topology, so that a node can discover routes to desired destinations.

Что в переводе на русский означает: каждая нода хранит у себя локально всю информацию о всех каналах.
Об этом писали парой постов выше. Так оно и есть значит.
Дальше по ссылке описываются технические детали того, как нода поддерживает у себя информацию о каналах в актуальном состоянии. То, что вы перевели к поиску маршрута не относится к сожалению.

В конце по ссылке даны рекомендации, как можно строить маршрут на примере одной прокладки между отправителем и получателем. Как строится маршрут с большим количеством прокладок, я не нашел.

Мне тут все понятно, кроме: откуда взять значение "xxxxxxxx"?

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

Хорошо.
Откуда берется это задание? Кто когда и как его раздает?

[QWeB]

То, что вы перевели к поиску маршрута не относится к сожалению.

Я привёл это потому, что именно на основе этой информации и строятся маршруты. Как можно написать про построение маршрутов без этого?
Если вы сами можете переводить BOLT, зачем вы спрашиваете у меня?

Откуда берется это задание? Кто когда и как его раздает?

Ясное дело, нода которая хочет совершить платёж.

Оптимальная маршрутизация это "секрет полковника Сандерса" каждого из производителей. Протокол даёт только общие рекомендации (как обычно, мой суверенный перевод):

Code:

Рекомендации по маршрутизации

При расчете маршрута для HTLC необходимо учитывать как cltv_expiry_delta, так и плату: cltv_expiry_delta влияет на время, когда средства будут недоступны в случае сбоя в худшем случае. Связь между этими двумя атрибутами неясна, так как зависит от надежности задействованных узлов.

Если маршрут вычисляется путем простой маршрутизации к предполагаемому получателю и суммирования cltv_expiry_deltas, тогда промежуточные узлы могут угадать свою позицию в маршруте. Знание CLTV(CheckLockTimeVerify) HTLC, топологии окружающей сети и cltv_expiry_deltas дает злоумышленнику возможность угадать предполагаемого получателя. Поэтому крайне желательно добавить случайное смещение к CLTV, которое получит предполагаемый получатель, что влияет на все CLTV на маршруте.

Чтобы создать правдоподобное смещение, исходный узел МОЖЕТ начать ограниченную случайную прогулку по графику, начиная с предполагаемого получателя и суммируя cltv_expiry_deltas, и использовать полученную сумму в качестве смещения. Это эффективно создает расширение теневого маршрута к фактическому маршруту и ​​обеспечивает лучшую защиту от этого вектора атаки, чем просто выбор случайного смещения.

Другие более сложные соображения включают в себя диверсификацию выбора маршрута, чтобы избежать единичных точек отказа и обнаружения, а также для балансировки локальных каналов.


Пример маршрутизации

Рассмотрим четыре узла:

   В
  / \
 /   \
A     C
 \   /
  \ /
   D

Каждый рекламирует следующий cltv_expiry_delta в конце каждого канала:

    A: 10 блоков
    Б: 20 блоков
    C: 30 блоков
    D: 40 блоков

C также использует min_final_cltv_expiry 9 (по умолчанию) при запросе платежей.

Кроме того, у каждого узла есть установленная схема оплаты, которую он использует для каждого из своих каналов:

    A: 100 базовая + 1000 millionths (пропорционально сумме платежа)
    B: 200 базовая + 2000 millionths
    C: 300 базовая + 3000 millionths
    D: 400 базовая + 4000 millionths

Сеть увидит восемь сообщений channel_update:

    A-> B: cltv_expiry_delta = 10, fee_base_msat = 100, fee_proportional_millionths = 1000
    A-> D: cltv_expiry_delta = 10, fee_base_msat = 100, fee_proportional_millionths = 1000
    B-> A: cltv_expiry_delta = 20, fee_base_msat = 200, fee_proportional_millionths = 2000
    D-> A: cltv_expiry_delta = 40, fee_base_msat = 400, fee_proportional_millionths = 4000
    B-> C: cltv_expiry_delta = 20, fee_base_msat = 200, fee_proportional_millionths = 2000
    D-> C: cltv_expiry_delta = 40, fee_base_msat = 400, fee_proportional_millionths = 4000
    C-> B: cltv_expiry_delta = 30, fee_base_msat = 300, fee_proportional_millionths = 3000
    C-> D: cltv_expiry_delta = 30, fee_base_msat = 300, fee_proportional_millionths = 3000

В-> С. Если бы B должен был отправить 4 999 999 миллисатоши непосредственно в C, он бы не взимал с себя плату и не добавлял свой собственный cltv_expiry_delta, поэтому он использовал бы запрошенный у min_final_cltv_expiry из 9. Предположительно, он также добавил бы теневой маршрут, чтобы дать дополнительный CLTV из 42. Кроме того, он может добавить дополнительные дельты CLTV в других переходах, так как эти значения представляют минимум, но решаем не делать этого здесь для простоты:

    amount_msat: 4999999
    cltv_expiry: current-block-height + 9 + 42
    onion_routing_packet:
        amt_to_forward = 4999999
        outgoing_cltv_value = current-block-height + 9 + 42

А-> В-> С. Если A должен был отправить 4 999 999 миллисатоши на C через B, ему необходимо заплатить B плату, указанную в B-> C channel_update, рассчитанную согласно платам HTLC:

    fee_base_msat + (amount_to_forward * fee_proportional_millionths / 1000000)

200 + (4999999 * 2000/1000000) = 10199

Точно так же необходимо добавить B_> C channel_update cltv_expiry (20), запрошенный C min_final_cltv_expiry (9) и стоимость теневого маршрута (42). Таким образом, сообщение update_add_htlc A-> B будет выглядеть так:

    amount_msat: 5010198
    cltv_expiry: current-block-height + 20 + 9 + 42
    onion_routing_packet:
        amt_to_forward = 4999999
        outgoing_cltv_value = current-block-height + 9 + 42

Update_add_htlc B-> C будет таким же, как и прямой платеж B-> C выше.

А-> D-> С. Наконец, если по какой-то причине A выберет более дорогой маршрут через D, сообщение update-add_htlc для A-> D будет выглядеть так:

    amount_msat: 5020398
    cltv_expiry: current-block-height + 40 + 9 + 42
    onion_routing_packet:
        amt_to_forward = 4999999
        outgoing_cltv_value = current-block-height + 9 + 42

И D-> C update_add_htlc снова будет таким же, как и прямой платеж B-> C выше.

П.С. в теме про новости Lightning network, у нас сегодня целая куча новостей )

[kzv]

Вобщем я примерно понял теперь суть.

1. Каждая нода LN хранит у себя всю информацию о всех открытых каналах.
Сейчас это немного, но в перспективе если все будет идти как задумано: каждый вася открывает канал к каждому ларьку в котором покупает или собирается купить пиво, размер базы LN будет сравним с размером блокчейна биткоина наверное.
Зато такая архитектура позволяет скрывать поиск маршрута от остальной сети, что конечно есть гуд.

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

Я во втором пункте не уверен. Кто-то может поправить?

[QWeB]

Я во втором пункте не уверен. Кто-то может поправить?

Отправителя никто не знает. Задание передаётся по цепочке. Никогда не ясно, тот, кто прислал тебе задание, является ли отправителем платежа, или такая же транзитная нода как и ты сам.

...размер базы LN будет сравним с размером блокчейна биткоина наверное.

Да хоть пять террабайт. Это в блокчейне никто не платит за полную ноду. А здесь в перспективе просматривается экономический стимул. (больше пяти не надо, у меня два винта по пять в рейде на ноде стоят)

Вобщем я примерно понял теперь суть.

Отлично, теперь как минимум один из участников текущего форума примерно понимает суть LN.

[kzv]

Я во втором пункте не уверен. Кто-то может поправить?

Отправителя никто не знает. Задание передаётся по цепочке. Никогда не ясно, тот, кто прислал тебе задание, является ли отправителем платежа, или такая же транзитная нода как и ты сам.

Как это реализовано?
Допустим есть маршрут А (отправитель) - Б - В - Г - Д (получатель)
Как отправитель А даст знать прокладке В, что когда он получит транзакцию от Б, то должен дальше передать транзакцию прокладке Г ?

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

ЗЫ Хотя нет, отправителя так не вычислить. Только получателя.

[QWeB]

Банковская система и биткоин не совместимы...

В моём лице вполне совместимы
Нужно же что-то кушать?

[GGUL]

Тут есть 2 нюанса.
1. Если Вася планирует через канал покупать пиво целый год, то он сразу должен вложить в канал годовую сумму. Другими словами, найти свободные(лишние) деньги и авансом заплатить за целый год. Кто так делает?  

В общем-то мы в фиатном мире так и делаем.

Нет, так мы не делаем. Мы не платим каждому предоставляющему нам услугу авансом на год, на полгода, даже на квартал.
Это требует море свободных денег. Которых, как мы знаем, обычно не хватает.

А твой пример с банком, если перевести его на каналы, соответствует тому , что Вася должен открыть ОДИН канал с крупной нодой.

2. Зачем Ларьку открывать канал с Васей? Ведь, теми средствами, которые Ларек будет получать через канал от Васи в течение года, Ларек сможет воспользоваться только тогда, когда закроется канал. То есть, весь год Ларек будет поить Васю за свой счет, в кредит.

Ларьку, ясен плинтус, не нужно открывать каналы на Васю. Ларьку надо открывать каналы на поставщиков.
А лучше всего на некий "банк" - ноду с большой связностью.

С поставщиками Ларьку и поставщику с Ларьком открывать каналы не имеет смысла. Это тот же самый платеж авансом на месяцы вперед со стороны Ларька. И поставщик не сможет воспользоваться средствами, пока не закроет канал.
А вот иметь  с "банком" толстый канал, смысл какой-то есть.

Вам не кажется, что концепция платежных каналов очень далека от жизненных реалий?

Мне не кажется.

Здесь подправлю.
Концепция платежных каналов в том смысле, что каждый открывает каналы со СВОИМИ контрагентами, очень далека от жизненных реалий.

И Васе, и Ларьку удобнее открывать канал с крупной нодой с большой связностью.  Сюда еще можно добавить тот факт, что чем крупнее нода, тем, скорее всего,  она эффективнее.
Значит, весь LN, в итоге, может вырасти в некую кальку нынешней банковской системы. Что, кстати, и утверждалось несколькими постами выше.

[QWeB]

Как это реализовано?

Переходим к следующей главе?
https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md

[QWeB]

И Васе, и Ларьку удобнее открывать канал с крупной нодой с большой связностью.  Сюда еще можно добавить тот факт, что чем крупнее нода, тем, скорее всего,  она эффективнее.
Значит, весь LN, в итоге, может вырасти в некую кальку нынешней банковской системы. Что, кстати, и утверждалось несколькими постами выше.

Ну да.
Получите нашу кредитную карту откройте канал с нашей нодой и получите кэшбэк до 10% процентов за покупки, и пропуск в бизнес зал в аэропорту