Хеш платежа

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

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

Хеш платежа начинается со своей противоположности: получатель выбирает 32 случайных байта, называемых прообразом платежа, и публикует только их SHA-256.

Это значение попадает в счет под тегом p, который BOLT 11 фиксирует как data_length длиной 52 и требует ровно один раз. Оттуда оно идет по маршруту внутри update_add_htlc, сообщения типа 128, поля которого таковы: идентификатор канала, 64-битный счетчик, сумма в миллисатоши, сам payment_hash, срок CLTV и луковичный пакет размером 1366 байт. В этом сообщении он выполняет двойную функцию: его также передают в построение луковицы как связанные данные, поэтому HMAC на каждом узле фиксируют его. Поэтому повторное использование старого луковичного пакета с другим хешем платежа терпит неудачу на первом же узле, который это проверяет.

Расчет проходит по хешу в обратном направлении. Получатель возвращает прообраз в update_fulfill_htlc, сообщении типа 130, как простое значение из 32 байт, и каждый узел выше по маршруту передает его обратно по тем же каналам. Узел, получивший прообраз, SHA-256 которого не совпадает с хешем, который он держит, не просто игнорирует его: BOLT 2 говорит, что он должен либо отправить предупреждение и закрыть соединение, либо отправить ошибку и сделать канал нерабочим, потому что невинного объяснения здесь нет.

В блокчейне хеш усекается. Скрипт выхода HTLC вообще не содержит значения из 32 байт; он выполняет сравнение OP_HASH160 с RIPEMD160(payment_hash), обязательством из 20 байт, а тратящий средства предоставляет прообраз в свидетеле. Два предложенных HTLC с одинаковой округленной суммой и одинаковым хешем платежа дают побайтно идентичные выходы, даже если их сроки различаются, поэтому BOLT 3 должен задавать правило их упорядочения.

Одно требование кажется странным, пока вы не увидите стоящую за ним атаку. Узел должен принимать несколько HTLC с одним и тем же хешем платежа, и BOLT 2 объясняет причину: если бы дубликаты отклонялись, злоумышленник мог бы прощупывать известным хешем и узнавать, держит ли этот узел уже данный платеж. Отдельный 64-битный идентификатор существует, чтобы различать дубликаты.

Почему это важно при покупке биткоина

Две из 63 криптобирж, обозреваемых на этом сайте, описывают выплату через Lightning в своих примечаниях о комиссиях: Strike, в примечании о выводе которой сказано, что вывод на кошельки поддерживается через Lightning и ончейн, и Coinbase, в таблице комиссий которой отправка через Lightning оценена в 0,2 % от отправленной суммы.

Когда одна из таких выплат застревает, нет идентификатора транзакции, который можно было бы проверить, потому что в блокчейн ничего не попало. Хеш платежа является единственной строкой, которая есть и в журнале вашего кошелька, и в операционном отделе биржи, поэтому скопируйте его с экрана деталей платежа, прежде чем закрыть его. Служба поддержки, которая просит «идентификатор транзакции» вывода через Lightning, просит именно это значение.

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

Одно и то же значение остается неизменным от вашего узла до узла получателя, в том числе во всех частях составного платежа, которые согласно BOLT 4 должны иметь единый хеш платежа. Тот, кто видит его дважды, знает, что перед ним один платеж. В нашем обзоре Phoenix цитируется собственный FAQ ACINQ, где компания признает, что знает конечный пункт назначения и сумму платежей, сделанных через кошелек; это прямая версия того же риска, заявленная поставщиком, а не выведенная этим сайтом.

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

Расшифровка хеша платежа в тестовом векторе пожертвования BOLT 11

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

Пример озаглавлен "Please make a donation of any amount using payment_hash 0001020304050607080900010203040506070809000102030405060708090102", а строка начинается с lnbc1pvjluez. После префикса lnbc и разделителя bech32 идет pvjluez, метка времени, 1496314658 секунд с начала 1970 года. Далее идет поле секрета платежа, а после него тег p, затем p5, то есть длина: в bech32 p означает 1, а 5 означает 20, поэтому поле занимает 1 * 32 + 20 = 52 символа. Эти символы, qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypq, декодируются в хеш, указанный в этом заголовке.

Ничто в нем не является приватным. Спецификация публикует приватный ключ, которым подписаны ее примеры, e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734, и говорит, что каждый счет в этом разделе несет секрет платежа 1111111111111111111111111111111111111111111111111111111111111111, если не указано иное, поэтому эти строки являются тестовыми данными для парсеров, а не запросами на оплату. Если кошелек или диагностический инструмент когда-либо покажет вам этот хеш вне набора тестов, значит, что-то повторяет спецификацию, а не сообщает о вашем платеже.

Хеш платежа vs идентификатор транзакции

Хеш платежа обозначает платеж Lightning; идентификатор транзакции обозначает транзакцию, которая существует в блокчейне биткоина. Оба занимают 32 байта и оба выводятся как 64 шестнадцатеричных символа, поэтому они и попадают в формы поддержки друг друга. Идентификатор транзакции вычисляется из собственных байтов транзакции задним числом и может быть вставлен в любой обозреватель блоков. Хеш платежа выбирается получателем до того, как платеж существует, никогда не появляется в блоке, когда платеж проходит нормально, и ничего не возвращает в обозревателе. Пустой результат поиска обычно означает, что у вас правильное значение и неправильный инструмент.

Хеш платежа vs секрет платежа

Хеш платежа и секрет платежа являются двумя разными значениями по 256 бит в одном и том же счете, которые переносятся в тегах p и s, причем каждое закодировано как 52 символа bech32. Хеш неизбежно публичен: каждый узел должен его видеть, чтобы построить свой HTLC. Секрет доставляется только последнему узлу, внутри луковицы, и BOLT 11 формулирует его задачу одной строкой: он "prevents forwarding nodes from probing the payment recipient" (не позволяет пересылающим узлам прощупывать получателя платежа). Программа, не нашедшая поля s, должна сразу сделать платеж неудачным. Хеш является замком; секрет является доказательством того, что плательщик получил счет от того, кто его выпустил.