Секрет платежа

Секрет платежа в Lightning работает как пароль для каждого счета, который плательщик возвращает, прежде чем принимающий узел примет деньги. BOLT 11 присваивает ему букву тега s, фиксирует длину в 52 символа bech32 и предписывает читателю отвергать любой счет, пришедший без него. Для вас это объясняет, почему маршрутизирующий узел, видевший ваш хеш платежа, не может определить, что платеж завершился в вашем кошельке.

Как это работает

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

BOLT 11 определяет его как тегированное поле типа 16, записываемое буквой s с фиксированным data_length, равным 52. Эти 52 символа bech32 несут 260 бит, то есть значение в 32 байта плюс заполнение, и составитель счета обязан включить ровно одно такое поле. Читающий обязан отклонить платеж, если поле фиксированной длины имеет неверную длину, а также если корректное поле s отсутствует.

Плательщик копирует значение в полезную нагрузку луковой маршрутизации для последнего узла, которую BOLT 4 называет TLV-записью типа 8, payment_data, содержащей секрет размером 32 байта и величину total_msat. Снять этот слой может только адресат, поэтому промежуточные узлы его никогда не видят, в отличие от хеша платежа, к которому все они привязывают свои HTLC.

Проверка на дальнем конце намеренно неинформативна. Секрет, не совпадающий с ожидаемым для данного хеша платежа, или обязательный, но отсутствующий, приводит к отказу HTLC с incorrect_or_unknown_payment_details, ошибкой PERM|15, то есть тем же ответом, который получает неизвестный хеш платежа. BOLT 4 объясняет это объединение: прежняя пара, PERM|16 incorrect_payment_amount и 17 final_expiry_too_soon, позволяла пересылающему узлу повторно отправлять платежи с тем же хешем на значительно меньшие суммы и по ответу выяснять, что он нашел адресата.

Поддержка больше не требует согласования. BOLT 9 перечисляет биты функциональности 14 и 15, payment_secret, как ASSUMED, а биты 16 и 17, basic_mpp, от него зависят.

Где это видно

Секрет платежа можно заметить в современной строке lnbc как участок, начинающийся с sp5 и имеющий длину 52 символа bech32.

В тестовых векторах BOLT 11 этот участок состоит из zyg3, повторенного двенадцать раз, а затем zygs, кодирующий секрет, все 32 байта которого равны 0x11. Секрет платежа никогда не приходится вводить вручную: значение обрабатывают только составитель счета и платящий кошелек.

Именно при многочастных платежах это поле особенно полезно. Когда ни один маршрут не располагает достаточной ликвидностью, а счет предлагает basic_mpp, BOLT 4 позволяет кошельку разделить сумму между несколькими HTLC с общим хешем платежа, и каждая часть должна нести секрет, а значения total_msat в них, как предполагается, совпадают. Получатель не завершает расчет, пока не придет вся сумма, и ему следует подождать не менее 60 секунд после первого HTLC, прежде чем отклонить набор с ошибкой mpp_timeout. Поэтому если более крупный вывод через Lightning из приложения, ориентированного прежде всего на Lightning, например Strike, минуту висит в ожидании, а затем возвращается, это может быть истечением неполного набора HTLC, а не потерей денег. Собирает ли эти части ваш собственный кошелек, как это делает Phoenix, запуская настоящий узел Lightning на смартфоне, или это делает кастодиальный посредник на сервере, который вы не контролируете, секрет помечает их как один платеж.

Секрет платежа vs хеш платежа

Хеш платежа и секрет платежа являются полями размером 256 бит в одном счете BOLT 11, и различие состоит в том, кто их видит. Каждый узел маршрута узнает хеш, поскольку каждый привязывает к нему пересылаемый HTLC, тогда как секрет знает только конечный узел, и он передается во внутреннем слое луковой полезной нагрузки. Хеш отвечает на вопрос, завершился ли платеж, а прообраз, открывающий его, служит квитанцией. Секрет отвечает на вопрос, работает ли плательщик с тем счетом, который составили вы, а хеш на это ответить не может, так как он виден всем на маршруте. В кодировке они выглядят близнецами: тег p и тег s, оба по 52 символа, оба отвергаются при любой другой длине.