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.