BOLT 12 — протокол узгодження платежу в Lightning Network. Він розрізняє пропозицію offer, запит invoice_request та підсумковий рахунок invoice. Пропозиція може залишатися опублікованою для багатьох платежів, а кожен рахунок визначає умови конкретної оплати.
Уявіть кав’ярню, яка хоче залишити на стійці один код для добровільних внесків. Повторна оплата того самого звичайного рахунку BOLT 11 створювала б проблеми. Натомість BOLT 12 публікує offer. Гаманець клієнта надсилає invoice_request, запитуючи власний рахунок, а одержувач відповідає новою invoice. Лише тоді її можна оплатити. Один надрукований QR служить різним людям без використання спільного рахунку. Отримати рахунок, наприклад через fetchinvoice, ще не означає надіслати гроші. Пропозиція також не дає кав’ярні права списувати подальші платежі з чужого гаманця. [1] [3] [4]
Пропозиція може вказувати ціну в біткоїні або іншій валюті. Поле offer_currency використовує коди ISO 4217; наприклад, суму в USD виражають у центах. Під час створення рахунку можуть враховувати кількість товарів і перерахунок валюти. Остаточна біткоїнова invoice_amount, однак, указана в millisatoshi, тобто тисячних частках satoshi: 1000 msat = 1 sat. Платник має знати цю суму й комісію до оплати, а не лише початковий цінник. Якщо запит визначає точну invreq_amount, рахунок повинен збігатися з нею. Інакше гаманець перевіряє дозволений діапазон і має запитати нову згоду за його межами. Перерахунок не повинен ставати непомітною згодою на будь-яку ціну. [1] [3]
Надрукований код може залишитися на стійці, але пропозиція теж може завершити дію в offer_absolute_expiry. Кожен рахунок додатково має час створення invoice_created_at і строк invoice_relative_expiry. Якщо строк не зазначений, типове значення — 7200 секунд, тобто дві години. Старий рахунок не є постійно чинним контактом. Гаманці також повинні розуміти обов’язкові можливості в повідомленнях. Невідомий парний біт означає необхідну функцію й призводить до відхилення; невідомий непарний є необов’язковим і його можна ігнорувати. Це безпечна сумісність, а не перешкода, яку користувач має обходити ручним переписуванням коду. [1]
Після оплати збережіть рахунок і результат із гаманця. До доказів розрахунку належить preimage — секретне значення, отримане під час завершення платежу. Гаманець обчислює з нього хеш, тобто контрольне значення, і порівнює його з платіжним хешем у рахунку. Разом із рахунком це дозволяє підтвердити оплату, але саме по собі не визначає, яка людина платила. Якщо застосунок від’єднався або втратив відповідь, спочатку перевірте стан попереднього платежу: новий рахунок може спричинити ще одну оплату. Так само уважно ставтеся до обіцянок регулярних платежів. Підтримка BOLT 12 не означає всіх розширень або дозволу на автоматичне списання. Окремо перевіряйте приймання платежів через пропозиції, оплату чужих пропозицій і права під’єднаного застосунку. [1] [3]
Запит рахунку й переказ використовують мережу для різних завдань. offer_paths спрямовує повідомлення із запитом, а invoice_paths задає маршрути платежу. BOLT 12 використовує blinded paths — шляхи, що приховують частину даних з’єднання до одержувача. Менше відкритих відомостей про структуру мережі допомагає приватності, але не обіцяє повної анонімності. Прихований шлях також не гарантує доступного одержувача чи ліквідності, тобто достатніх коштів на потрібних сторонах каналів. Технічно поточна invoice має містити ці шляхи й відповідні параметри invoice_blindedpay, навіть для прямого шляху до одержувача. Для запиту рахунку не потрібен звичайний платіжний сервер HTTPS. [1] [2]
Коли продавець хоче повернути гроші клієнту, напрям узгодження змінюється. Майбутній платник може опублікувати invoice_request без попередньої offer. Клієнт як одержувач відповідає власною invoice, яку продавець оплачує. Це не стирає й не відкликає початковий платіж, а створює новий у протилежний бік. Продавець повинен перевірити, що рахунок належить потрібному одержувачу, інколи шляхом домовленості поза протоколом. Саме сканування запиту не доводить права на повернення й не схвалює переказ. Технічний процес полегшує спілкування, але не вирішує, кому належать гроші. [1]
BOLT 12 зберігає дані як TLV: кожне поле вказує тип, довжину та значення. Текстова пропозиція починається з lno, запит — з lnr. Набір символів схожий на Bech32, але не має його кінцевої контрольної суми. Саме по собі це не визначає, кому слід платити. Offer не підписана. Цифрові підписи BIP340 Schnorr засвідчують рахунок і звичайний запит у відповідь на пропозицію. Окремий запит, опублікований без пропозиції, наприклад для повернення коштів, не містить підпису. Підпис пов’язаний із коренем структури Merkle — спільним контрольним значенням, обчисленим із відповідних полів. Так можна доводити окремі поля, не розкриваючи щоразу всіх подробиць. Це не дозволяє змінювати підписані умови й не доводить особу продавця за документами. [1]
Гаманець повинен установити, що отримав відповідь на свій запит, а не будь-який правильно підписаний рахунок. Він порівнює перенесені поля invoice_request з invoice, а також мережу, суму й підпис. Публічний ключ invoice_node_id має відповідати offer_issuer_id; коли пропозиція використовує відповідний прихований шлях без цього ідентифікатора, перевіряється його кінцевий blinded_node_id. Це схоже на перевірку, чи рахунок належить вашому столику, а не лише чи справжня на ньому печатка. Структура Merkle дозволяє вибіркові докази, але не звільняє гаманець від перевірки всіх потрібних умов. Чужий чинний рахунок не стає правильним лише тому, що його підпис пройшов перевірку. [1]
Для повної картини прочитайте також BOLT 11, Lightning Network, Lightning Routing, Приватність у Bitcoin, Satoshi, LNURL. На цю статтю також посилаються BOLT 11, LNURL, Just-in-Time Channels.