BOLT 12

Wyobraź sobie kawiarnię, która chce postawić na ladzie jeden kod do dobrowolnych wpłat. Wielokrotne płacenie tej samej zwykłej faktury BOLT 11 powodowałoby problemy. BOLT 12 publikuje zamiast niej offer. Portfel klienta wysyła invoice_request, prosząc o własną fakturę, a odbiorca odpowiada nową invoice. Dopiero ją można opłacić. Jeden wydrukowany QR służy więc różnym osobom bez używania przez wszystkich tej samej faktury. Uzyskanie jej, choćby przez fetchinvoice, nie wysyła jeszcze pieniędzy. Oferta nie upoważnia też kawiarni do pobierania kolejnych płatności z cudzego portfela. [1] [3] [4]

Oferta może podawać cenę w bitcoinie lub innej walucie. Pole offer_currency korzysta z kodów ISO 4217; przykładowo kwota w USD wyrażona jest w centach. Przy wystawianiu faktury można uwzględnić liczbę sztuk i przeliczenie waluty. Końcowe bitcoinowe invoice_amount podaje się jednak w millisatoshi, czyli tysięcznych częściach satoshi: 1000 msat = 1 sat. Przed zapłatą płacący musi znać tę kwotę i opłatę, nie tylko cenę na tabliczce. Jeśli żądanie wskazuje dokładną invreq_amount, faktura musi się z nią zgadzać. W przeciwnym razie portfel sprawdza dozwolony zakres i powinien poprosić o ponowną zgodę poza nim. Przeliczenie nie jest niewidoczną akceptacją dowolnej ceny. [1] [3]

Kod może zostać na ladzie, ale sama oferta może wygasnąć w offer_absolute_expiry. Każda faktura ma dodatkowo czas utworzenia invoice_created_at i okres ważności invoice_relative_expiry. Gdy okres nie jest podany, domyślnie wynosi 7200 sekund, czyli dwie godziny. Stara faktura nie jest więc bezterminowo ważnym kontaktem. Portfele muszą też rozumieć obowiązkowe funkcje wskazane w wiadomościach. Nieznany bit parzysty oznacza funkcję wymaganą i prowadzi do odrzucenia; nieznany nieparzysty jest opcjonalny i można go pominąć. Chodzi o bezpieczną zgodność, a nie przeszkodę, którą użytkownik powinien obchodzić ręcznym przepisywaniem kodu. [1]

Po zapłacie zachowaj fakturę i wynik z portfela. Dowodem rozliczenia jest także preimage — tajna wartość otrzymana przy zakończeniu płatności. Portfel oblicza z niej hash, czyli skrót kontrolny, i porównuje go z hashem płatności zapisanym w fakturze. W połączeniu z fakturą pozwala to wykazać, że została opłacona, ale samo w sobie nie wskazuje osoby, która zapłaciła. Jeśli aplikacja straci połączenie albo odpowiedź, przed kolejną próbą sprawdź stan poprzedniej płatności; nowa faktura może doprowadzić do następnej zapłaty. Równie ostrożnie czytaj obietnice płatności cyklicznych. Obsługa BOLT 12 nie oznacza automatycznie wszystkich rozszerzeń ani zgody na automatyczne obciążenia. Osobno sprawdź przyjmowanie płatności przez oferty, płacenie cudzych ofert oraz uprawnienia połączonej aplikacji. [1] [3]

Prośba o fakturę i transfer korzystają z sieci do różnych celów. offer_paths prowadzi wiadomość z żądaniem, a invoice_paths wskazuje trasy płatności. BOLT 12 używa blinded paths, ścieżek ukrywających część danych połączenia do odbiorcy. Mniej ujawnionych informacji o układzie sieci pomaga prywatności, ale nie obiecuje pełnej anonimowości. Ukryta trasa nie gwarantuje też dostępnego odbiorcy ani płynności, czyli wystarczających środków po potrzebnych stronach kanałów. Technicznie obecna invoice musi zawierać takie ścieżki i odpowiadające im parametry invoice_blindedpay, nawet przy drodze bezpośrednio do odbiorcy. Żądanie faktury nie wymaga zwykłego serwera płatniczego HTTPS. [1] [2]

Gdy sprzedawca chce zwrócić pieniądze, kierunek uzgodnień się odwraca. Przyszły płacący może opublikować invoice_request bez wcześniejszej offer. Klient jako odbiorca odpowiada własną invoice, którą sprzedawca opłaca. Nie usuwa to ani nie odwołuje pierwotnej płatności: jest nową płatnością w przeciwną stronę. Sprzedawca musi sprawdzić, czy faktura należy do zamierzonego odbiorcy, czasem przez kontakt poza protokołem. Samo skanowanie żądania nie dowodzi prawa do zwrotu ani nie zatwierdza przelewu. Procedura techniczna ułatwia komunikację, ale nie rozstrzyga, komu należą się pieniądze. [1]

BOLT 12 zapisuje dane jako TLV: każde pole podaje typ, długość i wartość. Oferta tekstowa zaczyna się od lno, żądanie od lnr. Zestaw znaków przypomina Bech32, ale bez jego końcowej sumy kontrolnej. To samo w sobie nie mówi, kto może otrzymać zapłatę. Offer nie jest podpisana. Podpisy cyfrowe BIP340 Schnorr uwierzytelniają fakturę i zwykłe żądanie będące odpowiedzią na ofertę. Samodzielne żądanie opublikowane bez oferty, na przykład w celu zwrotu pieniędzy, nie zawiera podpisu. Podpis wiąże się z korzeniem struktury Merkle — wspólnym skrótem kontrolnym obliczonym z odpowiednich pól. Można więc udowodnić wybrane pola bez ujawniania zawsze wszystkich szczegółów. Nie pozwala to zmieniać podpisanych warunków ani nie potwierdza tożsamości sprzedawcy. [1]

Portfel musi ustalić, że dostał odpowiedź na swoje żądanie, a nie dowolną poprawnie podpisaną fakturę. Porównuje przejęte pola invoice_request z invoice, a także sieć, kwotę i podpis. Klucz publiczny invoice_node_id musi odpowiadać offer_issuer_id; gdy oferta korzysta zamiast tego z odpowiedniej ukrytej ścieżki bez tej identyfikacji, sprawdza się jej końcowy blinded_node_id. To jak sprawdzenie, czy rachunek dotyczy twojego stolika, a nie tylko czy pieczątka jest prawdziwa. Struktura Merkle pozwala dowodzić wybranych danych, ale nie zwalnia portfela z kontroli wszystkich warunków potrzebnych do zapłaty. Cudza ważna faktura nie staje się właściwą tylko dlatego, że podpis przechodzi sprawdzenie. [1]