BOLT 11 — стандарт подписанного счёта Lightning в кодировке Bech32. Он содержит payment hash, сведения о получателе и условия платежа; это запрос, а не доказательство успешной оплаты.
Bech32 использует контрольную сумму против ошибок переписывания; это не шифрование. Подпись ECDSA на secp256k1 защищает содержимое и связывает его с ключом получателя, не с проверенной личностью. В отличие от адресов Bech32, BOLT 11 не ограничен 90 символами. QR допускает заглавные буквы; смешанный регистр недопустим. [BOLT 11 — Invoice protocol]
lnbc обозначает mainnet, lntb testnet, lntbs signet, lnbcrt regtest. Сумма выражается в BTC с множителем m, u, n или p. Для p последняя цифра должна быть 0, чтобы получить целые msat; 1000 msat — один satoshi. Отсутствующую сумму задаёт плательщик; это не нулевой платёж. [BOLT 11 — Invoice protocol]
Поле p содержит payment hash: SHA256 от payment preimage. Поле s содержит payment_secret, необходимый получателю в последней части маршрутизированного платежа. Secret не является preimage или seed кошелька. Текущий BOLT 11 требует оба поля; чтение secret из счёта не доказывает оплату. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
Счёт содержит ровно один вариант: текст d либо hash h внешнего описания. Для h кошелёк обязан проверить SHA256 полученного описания; сам хеш не объясняет покупку. Подпись связывает содержимое с ключом, но не удостоверяет обещание продавца. Декодированный текст нужно безопасно отображать как данные. [BOLT 11 — Invoice protocol]
Timestamp плюс x задаёт окончание срока; без x по умолчанию действуют 3600 секунд. Поле c — min_final_cltv_expiry_delta последнего HTLC в блоках, а не ещё один срок в секундах; при отсутствии применяется минимум 18 блоков. Истечение срока не отменяет завершённый платёж. [BOLT 11 — Invoice protocol]
Поле 9 обозначает обязательные и необязательные функции. Неизвестный чётный бит требует отказа, нечётный игнорируется; известные зависимости должны выполняться. Basic MPP разрешён только при предлагаемом basic_mpp. Разделение платежа не создаёт несколько независимых счетов. [BOLT 11 — Invoice protocol] [BOLT 9 — Assigned feature flags]
Поле r добавляет routing hints к получателю; оно может раскрыть ключи узлов, идентификаторы каналов и параметры комиссий. Это не доказательство текущей ликвидности. Необязательное f может предложить on-chain адрес — другой способ оплаты со своими комиссиями и подтверждениями. Счёт не является частным или постоянно многоразовым контактом. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
После отправки различайте ожидание и завершение. Сохраните счёт и соответствующий preimage как свидетельства расчёта, а не только снимок QR. При потере ответа сначала проверьте состояние кошелька. Новый счёт или другой способ может вызвать ещё одну оплату; сам формат не даёт универсальной защиты от повторений. [BOLT 4 — Onion routing] [Core Lightning — Payment result]
Для полной картины прочитайте эту статью вместе с Lightning Network, HTLC, BOLT 12, Nostr Wallet Connect, Satoshi. На эту статью также ссылаются Nostr Wallet Connect, BOLT 12, LNURL, Lightning Address.