BOLT 11

Анна купує електронну книжку. Замість банківських реквізитів магазин показує Lightning-рахунок, з якого гаманець читає платіжні дані. Анні не потрібно розуміти довгий рядок: перед підтвердженням вона перевіряє суму, призначення й комісію. Деякі рахунки не визначають суму, наприклад для добровільної підтримки. Тоді її вводить платник; відсутність суми не означає нульовий платіж. Для допитливих: lnbc позначає основну мережу, lntb — testnet, lntbs — signet, lnbcrt — regtest, тобто тестові середовища. Закодована сума вказана в BTC, за потреби з множником m, u, n або p, а не безпосередньо в satoshi. З p вона має закінчуватися цифрою 0, щоб відповідати цілим millisatoshi: 1000 msat = 1 sat. [1]

Опис пов’язує технічний запит із людською метою, наприклад із книжкою Анни. Рахунок містить або текст у полі d, або його цифровий відбиток у h. Відбиток обчислюється за допомогою SHA256; гаманець має перевірити, що опис, отриманий окремо, дає такий самий результат. Таке коротке контрольне значення, обчислене з тексту, називають хешем. Із самого відбитка замовлення не прочитаєш. Правильний підпис пов’язує опис із ключем одержувача, але не обіцяє, що продавець надішле книжку. Розробникам також слід пам’ятати: опис — чужий текст, який треба безпечно показувати як дані, а не виконувати як код. [1]

Анна залишає замовлення відкритим і повертається пізніше. Якщо гаманець повідомляє, що рахунок прострочений, їй слід запросити новий. Кінець чинності визначається часом створення timestamp і тривалістю x. Без x типовий строк становить 3600 секунд, тобто годину. Завершення строку не скасовує вже здійснений платіж. Поле c, технічно min_final_cltv_expiry_delta, визначає інше: часовий запас останнього умовного платежу HTLC на маршруті. HTLC дозволяє розрахунок за умови своєчасного надання правильного секрету. Запас вимірюють у блоках, не в секундах чинності рахунку; без c платник використовує щонайменше 18 блоків. Ці строки не можна плутати. [1]

Платіж Lightning проходить через платіжні канали. У каналі дві сторони оновлюють розподіл коштів, не записуючи кожен звичайний платіж в основний блокчейн Bitcoin. Для успішного платежу потрібні придатний маршрут і достатньо коштів на потрібних сторонах каналів — ліквідність. Поле r може містити routing hints, підказки для останньої ділянки. Вони допомагають знайти одержувача, але не показують доступну місткість у реальному часі. Також вони можуть розкривати публічні ключі вузлів, ідентифікатори каналів і параметри комісій, тому повний рахунок не слід вважати приватним. Необов’язкове поле f може запропонувати звичайну Bitcoin-адресу як запасний варіант. Платіж на неї йде основним ланцюгом, має окремі комісії та потребує підтверджень. Це не просто інша кнопка для того самого способу переказу. [1] [2] [5]

Відсканований QR або отриманий рахунок — не квитанція. Після надсилання перевіряйте результат у гаманці: очікування відрізняється від завершення. Розрахунок також засвідчує правильний preimage — секретне значення, хеш якого має відповідати платіжному хешу рахунку. Обидва можна зберегти як докази платежу, але не як гарантію доставки товару. Якщо застосунок від’єднався або втратив відповідь, спочатку перевірте стан початкового платежу. Негайний запит нового рахунку або оплата запасної адреси можуть призвести до повторної оплати. Деякі гаманці розпізнають повторні спроби, але сам формат не дає універсального захисту між застосунками й платіжними шляхами. [2] [4]

Довгий рядок використовує кодування Bech32. Його контрольна сума допомагає виявляти помилки переписування; це не шифрування і вона не приховує вміст. Цифровий підпис ECDSA на secp256k1 має інше завдання: перевірити зв’язок платіжних даних із ключем одержувача та відсутність подальших змін. Він не підтверджує особу за документами чи її чесність. На відміну від Bitcoin-адрес Bech32, BOLT 11 може перевищувати 90 символів. Для QR зручні великі літери, але правильний рядок не має змішувати великі й малі. Людина зазвичай сканує або копіює рахунок, а ці перевірки виконує гаманець. [1]

Payment hash — цифровий відбиток секретного payment preimage, обчислений за допомогою SHA256 і записаний у p. Після успішного розрахунку платник дізнається preimage та перевіряє відповідність відбитка. Поле s натомість містить payment_secret. Платник читає його вже з рахунку й передає одержувачу в останній ділянці маршруту; це допомагає захистити одержувача від зондування проміжними вузлами. Secret — не preimage і не seed гаманця. Прочитати його з QR не означає довести оплату чи отримати можливість відновлення гаманця. Поточний BOLT 11 вимагає p і s. Схожі назви приховують різні ролі: розпізнати платіж, передати потрібне значення й засвідчити розрахунок. [1] [2]

Гаманці також мають знати, чи підтримують потрібний платіж. Поле 9 містить прапорці можливостей. Невідомий парний біт означає обов’язкову функцію й вимагає відхилити платіж; непарний невідомий є необов’язковим і його можна ігнорувати. Відомі залежності між функціями теж мають виконуватися. Наприклад, Basic MPP розділяє платіж на частини, які збираються в одержувача. Його можна застосовувати лише тоді, коли рахунок пропонує basic_mpp. Це не створює кількох незалежних рахунків і не дає підстав платити за кожну частину знову. Для початківця висновок простий: не обходьте повідомлення про непідтримувану функцію ручним редагуванням рахунку, а спочатку вирішіть питання сумісності гаманців. [1] [3]