Проверяйте zap-квитанции NIP-57 перед подсчетом

Zap в Nostr обычно оставляет событие вида 9735, которое называется zap-квитанцией. Это полезное свидетельство, но один только вид события почти ничего не доказывает. Клиент, считающий каждое событие 9735, может принять подпись постороннего ключа, измененную сумму, другого получателя или квитанцию от другой цели.

NIP-57 задает цепочку связанных данных: подписанный zap-запрос вида 9734, ответ LNURL-pay, счет BOLT11 и подписанную квитанцию вида 9735. Проверка означает проверку каждого звена. Но даже после нее результат остается подписанным заявлением LNURL-сервера получателя, а не доказательством расчета Lightning без доверия.

Начните с корректного события Nostr

Сначала проверьте квитанцию как обычное событие Nostr по NIP-01. Пересчитайте ID из канонической сериализации и проверьте подпись Schnorr по pubkey. Отклоните некорректные теги и убедитесь, что kind равен 9735.

Копии одного события на разных реле сохраняют одинаковый ID. Перед подсчетом удаляйте дубликаты по ID, иначе одна квитанция с нескольких реле будет учтена несколько раз.

Поле content должно быть пустым. Полезные данные находятся в тегах:

bolt11 содержит счет Lightning;
description содержит JSON подписанного запроса вида 9734;
p указывает получателя;
необязательные e и a указывают событие или адресуемое событие;
необязательный P указывает отправителя из запроса.

Свяжите автора с LNURL-сервисом

Открытый ключ квитанции должен совпадать с nostrPubkey, полученным от LNURL-pay получателя. Корректная подпись Nostr любого другого ключа не делает квитанцию действительной для данного платежа.

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

Проверьте встроенный zap-запрос

Разберите тег description как исходное событие вида 9734, затем проверьте его ID и подпись. NIP-57 требует правильную структуру запроса: ровно один тег p, не более одного тега e, a или P, а также тег relays с адресами публикации квитанции.

Сравните запрос с квитанцией. Квитанция должна копировать p и имеющиеся теги e, a, P. Если получатель или цель отличаются, не учитывайте ее для открытой страницы, профиля или события.

Если запрос содержит lnurl, по NIP-57 он должен совпадать с LNURL получателя. Несовпадение означает разрыв связи, а не безобидное изменение метаданных.

Согласуйте счет и сумму

Декодируйте счет bolt11, не доверяя показанной сумме. Если в запросе есть amount, сумма счета должна точно совпадать. Запрос к callback LNURL тоже должен использовать эту сумму.

Хеш описания в BOLT11 должен совпадать с SHA-256 точной JSON-строки из тега description. Это мешает позднее прикрепить действительный счет к другому zap-запросу. Хешируйте исходные байты: разбор и повторная сериализация JSON могут изменить пробелы или порядок ключей.

В квитанции может быть тег preimage. Его хеш можно сравнить с payment hash счета, но NIP-57 предупреждает, что это не существенное независимое доказательство: получатель создал счет и после расчета знает preimage.

Понимайте предел доказательства

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

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

Практический порядок проверки

Проверьте ID и подпись события 9735.
Удалите дубликаты ID с разных реле.
Сверьте автора с LNURL nostrPubkey, использованным для счета.
Разберите и проверьте встроенный запрос 9734.
Сравните связи p, e, a, P и необязательный lnurl.
Декодируйте BOLT11 и сравните сумму с запросом.
Сверьте хеш описания с точной строкой description.
Представляйте результат как подписанное заявление сервера, а не независимое доказательство платежа.

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