BOLT 11

Anna kupuje ebook. Zamiast danych bankowych sklep pokazuje fakturę Lightning, z której portfel odczytuje dane płatności. Anna nie musi rozumieć długiego ciągu znaków: przed zatwierdzeniem sprawdza kwotę, cel i opłatę. Niektóre faktury nie określają kwoty, na przykład przy dobrowolnym wsparciu. Wpisuje ją wtedy płacący; brak kwoty nie oznacza zerowej płatności. Dla ciekawych: lnbc oznacza sieć główną; lntb to testnet, lntbs — signet, a lnbcrt — regtest, czyli środowiska testowe. Zakodowana kwota jest w BTC, ewentualnie z mnożnikiem m, u, n lub p, a nie bezpośrednio w satoshi. Przy p musi kończyć się cyfrą 0, aby wyrażała całe millisatoshi: 1000 msat = 1 sat. [1]

Opis łączy techniczne żądanie z ludzkim celem, choćby książką Anny. Faktura zawiera sam tekst w polu d albo jego cyfrowy odcisk w h. Odcisk powstaje za pomocą SHA256; portfel musi sprawdzić, czy opis dostarczony osobno daje ten sam wynik. Taki krótki wynik obliczenia z tekstu nazywa się hashem, czyli skrótem kontrolnym. Z samego odcisku nie odczytasz zamówienia. Poprawny podpis wiąże opis z kluczem odbiorcy, lecz nie obiecuje, że sprzedawca dostarczy książkę. Twórca aplikacji musi też pamiętać, że opis jest obcym tekstem: należy bezpiecznie wyświetlać go jako dane, nigdy wykonywać jako kod. [1]

Anna zostawia otwarte zamówienie i wraca później. Gdy portfel zgłasza wygaśnięcie faktury, powinna poprosić o nową. Koniec ważności wynika z chwili utworzenia timestamp i czasu x. Jeśli x nie ma, domyślnie obowiązuje 3600 sekund, czyli godzina. Wygaśnięcie nie cofa zakończonej płatności. Pole c, technicznie min_final_cltv_expiry_delta, określa coś innego: zapas czasu ostatniej płatności warunkowej HTLC na trasie. HTLC uzależnia rozliczenie od przedstawienia właściwego sekretu w terminie. Ten zapas mierzy się w blokach, nie w sekundach ważności faktury; bez c płacący przyjmuje co najmniej 18 bloków. Tych dwóch terminów nie wolno mylić. [1]

Płatność Lightning przechodzi przez kanały płatnicze. W kanale dwie strony aktualizują podział środków bez zapisywania każdej zwykłej płatności w głównym blockchainie Bitcoin. Aby płatność dotarła, potrzeba dostępnej trasy i wystarczających środków po odpowiednich stronach kanałów, czyli płynności. Pole r może zawierać routing hints — wskazówki dotyczące ostatniego odcinka. Pomagają dotrzeć do odbiorcy, ale nie pokazują jego aktualnej dostępnej przepustowości. Mogą też ujawnić klucze publiczne węzłów, identyfikatory kanałów i parametry opłat, więc całej faktury nie należy traktować jako prywatnej. Opcjonalne pole f może proponować zwykły adres Bitcoin jako rozwiązanie zastępcze. Płatność na niego trafia do głównego łańcucha, ma własne opłaty i wymaga potwierdzeń. Nie jest to tylko inny przycisk dla tej samej drogi dostarczenia. [1] [2] [5]

Zeskanowany QR ani otrzymana faktura nie są pokwitowaniem. Po wysłaniu sprawdź wynik w portfelu: płatność oczekująca różni się od zakończonej. Rozliczenie potwierdza również właściwy preimage, tajna wartość, której hash musi odpowiadać hashowi płatności na fakturze. Fakturę i tę wartość można zachować jako dowody płatności, ale nie jako gwarancję dostawy. Jeśli aplikacja straci połączenie lub odpowiedź, najpierw sprawdź stan pierwotnej płatności. Natychmiastowe wystawienie nowej faktury albo użycie adresu zastępczego może oznaczać zapłatę drugi raz. Niektóre portfele rozpoznają ponowienia, lecz sam format nie daje uniwersalnej ochrony między aplikacjami i sposobami płacenia. [2] [4]

Długi ciąg znaków wykorzystuje kodowanie Bech32. Jego suma kontrolna pomaga wychwycić błędy przepisywania; nie jest szyfrowaniem i nie ukrywa treści. Podpis cyfrowy ECDSA na secp256k1 ma inne zadanie: pozwala sprawdzić powiązanie danych płatności z kluczem odbiorcy oraz brak późniejszych zmian. Nie potwierdza tożsamości ani uczciwości osoby za tym kluczem. W przeciwieństwie do adresów Bitcoin Bech32, BOLT 11 może przekraczać 90 znaków. Wielkie litery dobrze nadają się do QR, lecz poprawny ciąg nie może mieszać wielkich i małych liter. Człowiek zwykle skanuje lub kopiuje, a kontrole wykonuje portfel. [1]

Payment hash jest cyfrowym odciskiem tajnej wartości payment preimage, obliczonym przez SHA256 i zapisanym w polu p. Po rozliczeniu płacący poznaje preimage i może sprawdzić zgodność odcisku. Pole s zawiera natomiast payment_secret. Płacący odczytuje go już z faktury i przekazuje odbiorcy w ostatnim odcinku kierowanej płatności; pomaga to chronić odbiorcę przed sondowaniem przez pośredniczące węzły. Secret nie jest preimage ani seedem portfela. Odczytanie go z QR nie dowodzi zapłaty i nie pozwala odtworzyć portfela. Aktualny BOLT 11 wymaga pól p oraz s. Podobne nazwy kryją różne role: rozpoznanie płatności, przekazanie potrzebnej wartości i wykazanie rozliczenia. [1] [2]

Portfele muszą też wiedzieć, czy obsługują daną płatność. Pole 9 zawiera znaczniki funkcji. Nieznany bit parzysty oznacza funkcję obowiązkową i wymaga odrzucenia płatności; nieznany nieparzysty jest opcjonalny i można go pominąć. Trzeba również spełnić znane zależności między funkcjami. Basic MPP dzieli na przykład jedną płatność na części łączone u odbiorcy. Wolno go użyć tylko wtedy, gdy faktura oferuje basic_mpp. Podział nie tworzy kilku niezależnych faktur ani powodu do ponownego płacenia każdej części. Dla początkujących wniosek jest prosty: nie obchodź komunikatu o nieobsługiwanej funkcji przez ręczne zmiany faktury; najpierw rozwiąż problem zgodności portfeli. [1] [3]