BOLT 12 to protokół uzgadniania płatności Lightning poprzez offer, invoice_request i invoice. Oferta jest wielorazowa, lecz każda płatność ma własne warunki i wynik do sprawdzenia.
Odbiorca publikuje offer; płacący wysyła invoice_request i otrzymuje nową invoice. Dopiero potem może zapłacić. Oferta może służyć wielu osobom lub powtarzanym płatnościom. Pobranie faktury, np. przez fetchinvoice, nie opłaca jej; publiczny QR nie jest stałą zgodą na obciążanie. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice] [BOLT 12 — Project overview]
BOLT 12 zapisuje pola jako TLV. Tekstowe oferty mają prefiks lno, żądania lnr; alfabet przypomina Bech32, ale bez końcowej sumy kontrolnej. Sama offer nie jest podpisana. Podpisy Schnorr BIP340 w żądaniach i fakturach sprawdzają korzeń Merkle pól, nie tożsamość sprzedawcy. [BOLT 12 — Negotiation protocol]
Portfel porównuje skopiowane pola invoice_request z invoice, kwotą, łańcuchem i podpisem. invoice_node_id musi odpowiadać offer_issuer_id lub właściwemu końcowemu blinded_node_id. Poprawny obcy podpis nie wystarcza. Struktura Merkle umożliwia selektywne dowody pól, nie dowolną zmianę podpisanych warunków. [BOLT 12 — Negotiation protocol]
Bitcoinowa invoice_amount jest w msat; 1000 msat to jeden satoshi. offer_currency może podawać inną walutę według ISO 4217; USD używa centów. Na cenę wpływa liczba sztuk i ewentualne przeliczenie przy wystawieniu. Jeśli podano invreq_amount, faktura musi się zgadzać; inaczej sprawdza się zatwierdzony zakres. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
offer_paths prowadzi wiadomość z żądaniem, invoice_paths płatność. Obecna invoice musi zawierać blinded paths i odpowiadające invoice_blindedpay, nawet przy trasie bezpośredniej do odbiorcy. Zaślepienie ogranicza ujawnienie topologii, lecz nie gwarantuje pełnej anonimowości, dostępności ani płynności. Żądanie faktury nie wymaga zwykłego serwera płatniczego HTTPS. [BOLT 12 — Negotiation protocol] [BOLT 4 — Route blinding]
offer_absolute_expiry ogranicza ofertę. invoice_created_at wraz z invoice_relative_expiry ogranicza konkretną fakturę; bez drugiego pola obowiązuje 7200 sekund. Wielorazowa oferta nie daje fakturom nieograniczonej ważności. Nieznane parzyste bity obowiązkowe są odrzucane, nieparzyste ignorowane. [BOLT 12 — Negotiation protocol]
Przy zwrocie wysyłający pieniądze może opublikować invoice_request bez offer. Odbiorca pieniędzy odpowiada własną invoice; płacący musi zweryfikować zamierzonego odbiorcę, w razie potrzeby poza protokołem. To nowa płatność, nie anulowanie poprzedniej. Samo skanowanie nie dowodzi uprawnienia ani zgody na zapłatę. [BOLT 12 — Negotiation protocol]
Zachowaj invoice, stan płatności i pasujące preimage. Preimage dowodzi rozliczenia faktury, ale samo nie wskazuje człowieka, który płacił. Po utracie odpowiedzi sprawdź stan przed następną zapłatą. Obsługa ofert nie oznacza każdej funkcji dodatkowej ani automatycznych płatności cyklicznych; osobno sprawdź odbiór, wysyłanie i uprawnienia aplikacji. [BOLT 12 — Negotiation protocol] [Core Lightning — Fetching an invoice]
Pełniejszy obraz uzyskasz, czytając to hasło razem z BOLT 11, Lightning Network, Lightning Routing, Prywatność w Bitcoinie, Satoshi, LNURL. Do tego hasła prowadzą również odsyłacze z BOLT 11, LNURL.