BOLT 12 — протокол узгодження платежу Lightning через offer, invoice_request та invoice. Пропозиція багаторазова, але кожен платіж має власні умови й результат для перевірки.
Одержувач публікує offer; платник надсилає invoice_request та отримує нову invoice. Лише потім він може заплатити. Пропозиція може слугувати різним людям чи повторним платежам. Отримання рахунку, наприклад через fetchinvoice, не оплачує його; публічний QR не є постійним дозволом на списання. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]
BOLT 12 зберігає поля як TLV. Текстові пропозиції мають префікс lno, запити lnr; алфавіт схожий на Bech32, але без кінцевої контрольної суми. Сама offer не підписана. Підписи Schnorr BIP340 у запитах і рахунках перевіряють корінь Merkle полів, не особу продавця. [BOLT 12 — Negotiation protocol]
Гаманець порівнює скопійовані поля invoice_request з invoice, сумою, мережею й підписом. invoice_node_id має відповідати offer_issuer_id або належному кінцевому blinded_node_id. Чинного стороннього підпису недостатньо. Структура Merkle дозволяє вибіркові докази полів, не довільну зміну підписаних умов. [BOLT 12 — Negotiation protocol]
Bitcoin invoice_amount задається в msat; 1000 msat — один satoshi. offer_currency може вказувати іншу валюту за ISO 4217; USD, наприклад, використовує центи. На ціну впливають кількість і перерахунок при виставленні рахунку. Якщо визначено invreq_amount, рахунок має збігатися; інакше перевіряють дозволений діапазон. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
offer_paths веде повідомлення із запитом, invoice_paths — платіж. Поточна invoice має містити blinded paths і відповідний invoice_blindedpay, навіть за прямого маршруту до одержувача. Засліплення обмежує розкриття топології, але не гарантує повної анонімності, доступності чи ліквідності. Запит рахунку не потребує звичайного платіжного HTTPS сервера. [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]
offer_absolute_expiry обмежує пропозицію. invoice_created_at разом з invoice_relative_expiry обмежує конкретний рахунок; без другого поля діють 7200 секунд. Багаторазовість не надає рахункам безмежного строку. Невідомі парні обов’язкові біти відхиляють, невідомі непарні ігнорують. [BOLT 12 — Negotiation protocol]
Для повернення той, хто хоче надіслати гроші, може опублікувати invoice_request без offer. Одержувач грошей відповідає власною invoice; платник має перевірити потрібного одержувача, за потреби поза протоколом. Це новий платіж, не скасування старого. Саме сканування не доводить права на кошти чи дозволу платити. [BOLT 12 — Negotiation protocol]
Зберігайте invoice, стан платежу та відповідний preimage. Preimage доводить розрахунок за рахунком, але сам не визначає людину-платника. Після втрати відповіді перевірте стан перед новою оплатою. Підтримка пропозицій не означає всіх розширень чи автоматичних регулярних платежів; окремо перевіряйте приймання, надсилання та дозволи застосунку. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
Для повної картини прочитайте також BOLT 11, Lightning Network, Lightning Routing, Приватність у Bitcoin, Satoshi, LNURL. На цю статтю також посилаються BOLT 11, LNURL.