Инвойс Lightning формата BOLT11 — закодированный запрос на оплату, а не зашифрованное личное сообщение. Получатель полного текста или читаемого QR-кода может разобрать описание, сумму и другие поля. Набор данных зависит от конкретного счёта. Поэтому инвойс стоит передавать тому, кому он нужен для платежа или разбора проблемы, а не публиковать как безобидную техническую строку.
Сначала выясните, какое описание вы отправляете
На экране кошелька бывает короткая подпись, тогда как кнопка копирования выдаёт длинный запрос. Подпись может оказаться описанием из самого инвойса либо отдельной заметкой пользователя. Это разные записи. Если вы после оплаты переименовали операцию у себя в приложении, содержание уже переданного другому человеку инвойса от этого не изменилось.
В спецификации BOLT11 предусмотрены текстовое описание и альтернативное поле с хешем описания. Текст, включённый непосредственно в счёт, можно прочитать при декодировании. Хеш позволяет сверить описание, переданное отдельно. Он не означает, что исходного текста нигде нет или что другие записи нельзя связать с этим запросом.
Например, в описание иногда попадают имя клиента, электронная почта и подробности заказа. Для публичного вопроса о том, почему кошелёк показывает истёкший срок, эти сведения обычно лишние. При создании счёта оставляйте необходимые данные, а посторонние личные заметки храните отдельно. Это не отменяет требований к учёту и документам: сокращение лишних сведений не предполагает искажения назначения платежа.
Что означают прочитанные поля
| Поле или запись | Что можно узнать | Какого вывода недостаточно |
|---|---|---|
| Описание | Текст составителя, если выбран такой вариант | Что текст скрыт или проверен независимой стороной |
| Хеш описания | Значение для сверки отдельно переданного текста | Что перед нами зашифрованное описание |
| Сумма | Запрошенную величину, когда она задана | Что именно столько уже получено |
| Время создания и срок | Когда появился запрос и сколько он действителен | Когда завершился платёж |
| Подписант или назначение | Публичный ключ, связанный с запросом | Юридическую личность человека |
| Подсказки маршрутизации | Дополнительные сведения для построения маршрута | Полный путь отправителя и остатки каналов |
| Хеш платежа | Идентификатор, связанный с запрошенным платежом | Факт оплаты по одному наличию хеша |
В описании декодера LND эти поля разделены. У обычного запроса без ослеплённого пути назначением выступает публичный ключ принимающего узла. Новые варианты с ослеплёнными путями требуют отдельного прочтения. Даже привычную техническую подпись назначения нельзя автоматически превращать в имя владельца: обслуживающую инфраструктуру может предоставлять сторонний сервис.
Инвойс без заранее указанной суммы — ещё одна причина не принимать скриншот за подтверждение поступления. Сумму может выбрать плательщик позже. Срок действия относится к возможности использовать запрос, а не к ожиданию зачисления уже отправленных средств. Декодер прочитает и старый инвойс, который никто не пытался оплатить. Успешный разбор строки подтверждает её содержимое, но не историю исполнения.
QR-код и хеш не дают одинаковой защиты
QR-код лишь упрощает перенос запроса в другое приложение. Он не скрывает поля от читателя. Если на скриншоте закрыть подпись, но оставить сканируемый код, исходное описание может остаться доступным. Когда нужно показать только ошибку, удалите из изображения и сам запрос либо перепишите сообщение об ошибке без платёжных реквизитов.
Хеш отличается от открытого текста, но называть его шифрованием неправильно. Само описание может поступать вместе с процессом оплаты, храниться у сервиса или находиться в той же переписке. Проверяйте весь публикуемый набор: инвойс, страницу заказа, подпись к изображению и название файла. Отдельное поле не исправляет раскрытие данных в остальных частях этого набора.
Подсказки маршрутизации тоже нельзя читать как протокол завершённого перевода. Они помогают найти путь к получателю, но не показывают все рассмотренные отправителем маршруты и остатки каждого канала. В руководстве Bitcoin Design по форматам запросов можно сверить различия форматов. Не переносите полный список полей BOLT11 на любой объект со словом Lightning.
Подготовьте запись для поддержки без лишних данных
- Определите формат запроса и конкретную проблему кошелька. Здесь разбирается BOLT11; предложения BOLT12 и Lightning-адреса устроены иначе.
- Посмотрите поля в доверенном кошельке или декодере. До вставки действующего инвойса выясните, обрабатывает ли инструмент строку локально или отправляет её на сервер.
- Разделите исходный счёт, результат платежа и личные заметки. Сохраните оригиналы отдельно: обрезанный скриншот не должен остаться единственным свидетельством.
- В официальную поддержку передайте сообщение об ошибке, версию приложения, время и нужный идентификатор. Полный запрос отправляйте, если он требуется для разбора.
- Для публичного вопроса уберите строку инвойса, QR-код и посторонние личные подписи. Обезличенный пример часто объясняет проблему без раскрытия действующего запроса.
Декодер инвойсов Lightning помогает читать поля, если вы готовы передать ему выбранные данные. Это не утверждение о способе обработки ввода и не подтверждение личности получателя. Если вопрос касается совместимости форматов, сначала посмотрите разницу между инвойсом и адресом Bitcoin. Не подбирайте реквизиты по похожему названию.
Не превращайте технический вопрос в досье
Представим вымышленный счёт с описанием «Заказ Сад-41» и отдельную заметку кошелька с почтой клиента. Инвойс и заметка раскрывают разные сведения. Удалив почту из заметки, вы не удалите Сад-41 из самого счёта. Если этот номер связан с открытой страницей заказа, где есть личные данные, объединённая публикация раскрывает ещё больше. Ни одна из перечисленных связей сама по себе не доказывает завершение оплаты.
Свидетельство исполнения храните в отправляющем или принимающем кошельке отдельно от запроса. Если сервис просит подтвердить платёж, уточните необходимые данные в официальной переписке вместо публикации полной истории. Открытый инвойс не обязательно раскрывает личность плательщика. Но отсутствие имени в строке также не доказывает, что другие записи нельзя связать с конкретным человеком.
При обмене без регистрации проверяйте сеть и формат назначения по инструкции конкретной заявки. Само наличие Bitcoin не означает приём Lightning-инвойсов. Практический вопрос приватности здесь простой: плательщику нужны действующие реквизиты, поддержке — сведения для диагностики, а открытой дискуссии обычно достаточно описания ошибки. Сохраняйте полезные доказательства у себя, передавая каждому адресату только необходимую для его задачи часть.
Частые вопросы
Какие данные показывает декодер BOLT11?
В зависимости от счёта он читает описание, сумму, время, срок действия и сведения для маршрутизации. Это разбор запроса, а не доказательство исполнения платежа или юридической личности владельца узла.
Видно ли описание в примере Lightning invoice с QR-кодом?
Если описание включено в запрос открытым текстом, читаемый QR-код позволяет получить его после декодирования. Скрытая подпись на скриншоте не поможет, пока сам код остаётся доступным.
Заметка в кошельке меняет описание инвойса Lightning?
Отдельная заметка приложения не переписывает ранее переданный инвойс. Перед публикацией проверьте, какой текст входит в запрос, а какой сохранён только в записях вашего кошелька.