BOLT 11 to standard podpisanej faktury Lightning kodowanej w Bech32. Zawiera payment hash, dane odbiorcy i warunki płatności; jest żądaniem, a nie dowodem udanej zapłaty.
Bech32 ma sumę kontrolną wykrywającą błędy przepisywania; nie szyfruje. Podpis ECDSA na secp256k1 chroni treść i wiąże ją z kluczem odbiorcy, nie ze zweryfikowaną osobą. W odróżnieniu od adresów Bech32 BOLT 11 nie ma limitu 90 znaków. QR może używać wielkich liter; mieszana wielkość jest niepoprawna. [BOLT 11 — Invoice protocol]
lnbc oznacza mainnet, lntb testnet, lntbs signet, a lnbcrt regtest. Kwota jest w BTC z mnożnikiem m, u, n lub p. Przy p ostatnią cyfrą musi być 0, aby uzyskać całe msat; 1000 msat to jeden satoshi. Brak kwoty oznacza jej podanie przez płacącego, nie płatność zerową. [BOLT 11 — Invoice protocol]
Pole p zawiera payment hash: SHA256 z payment preimage. Pole s zawiera payment_secret wymagany przez odbiorcę w końcowej części routowanej płatności. Secret nie jest preimage ani seedem portfela. Obecny BOLT 11 wymaga obu pól; odczytanie secret z faktury nie dowodzi zapłaty. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
Faktura zawiera dokładnie jeden wariant: tekst d albo hash h zewnętrznego opisu. Przy h portfel musi sprawdzić SHA256 dostarczonego opisu; sam hash nie wyjaśnia zakupu. Podpis wiąże treść z kluczem, nie potwierdza obietnicy sprzedawcy. Zdekodowany tekst należy bezpiecznie wyświetlać jako dane. [BOLT 11 — Invoice protocol]
Timestamp plus x określa wygaśnięcie; bez x domyślnie obowiązuje 3600 sekund. Pole c to min_final_cltv_expiry_delta ostatniego HTLC w blokach, nie kolejny czas ważności w sekundach; bez niego stosuje się co najmniej 18 bloków. Wygaśnięcie nie cofa zakończonej płatności. [BOLT 11 — Invoice protocol]
Pole 9 wskazuje funkcje wymagane i opcjonalne. Nieznany parzysty bit wymaga odrzucenia, nieznany nieparzysty jest ignorowany; znane zależności muszą być spełnione. Basic MPP wolno użyć tylko przy oferowanym basic_mpp. Podział płatności nie tworzy kilku niezależnych faktur. [BOLT 11 — Invoice protocol] [BOLT 9 — Assigned feature flags]
Pole r dodaje routing hints prowadzące do odbiorcy; może ujawnić klucze węzłów, identyfikatory kanałów i parametry opłat. Nie dowodzi bieżącej płynności. Opcjonalne f może podać adres on-chain, czyli inną metodę płatności z własnymi opłatami i potwierdzeniami. Faktura nie jest prywatnym ani stale wielorazowym kontaktem. [BOLT 11 — Invoice protocol] [BOLT 4 — Onion routing]
Po wysłaniu odróżniaj wynik oczekujący od zakończonego. Zachowaj fakturę i pasujące preimage jako dowody rozliczenia, nie tylko zrzut QR. Po utracie odpowiedzi najpierw sprawdź stan portfela. Nowa faktura lub inna metoda może spowodować kolejną płatność; sam format nie zapewnia uniwersalnej ochrony przed powtórzeniem. [BOLT 4 — Onion routing] [Core Lightning — Payment result]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Lightning Network, HTLC, BOLT 12, Nostr Wallet Connect, Satoshi. Do tego hasła prowadzą również odsyłacze z Nostr Wallet Connect, BOLT 12, LNURL, Lightning Address.