LNURL to rodzina procedur, za pomocą których portfel Lightning i serwis internetowy wymieniają dane potrzebne do wykonania zadania. Lightning służy do szybkich płatności bitcoinem; faktura w tej sieci to żądanie zapłaty zawierające dane potrzebne portfelowi do wykonania płatności. Z linku portfel dowiaduje się, czy ma przygotować płatność, odebrać wypłatę, czy potwierdzić logowanie. Sam link nie jest fakturą ani dowodem, że pieniądze dotarły.
Wyobraź sobie Annę, która skanuje kod, by wesprzeć autora, potem kolejny, by zrealizować voucher, a na końcu kod logowania do serwisu. Za każdym razem podobnie używa telefonu, ale zatwierdza coś innego. LNURL rozróżnia te zadania: payRequest oznacza płatność, withdrawRequest wypłatę, a login logowanie. Poszczególne procedury opisują dokumenty LUD. Są to opcjonalne zasady współpracy aplikacji, a nie zmiana reguł Bitcoina. Obsługa jednej procedury przez portfel nie oznacza obsługi wszystkich pozostałych. [1] [7]
Przy payRequest serwis zwraca opis i dozwolony zakres kwot. Anna sprawdza domenę, czyli adres internetowy usługi, czyta opis i wybiera kwotę wsparcia. Po zaakceptowaniu warunków portfel prosi o konkretną fakturę Lightning BOLT 11 i przed zapłatą sprawdza, czy kwota zgadza się z wyborem. Korzysta z adresu callback, limitów minSendable i maxSendable oraz opisu metadata; wysyła kwotę jako amount i otrzymuje fakturę w pr. Kwoty są podawane w msat, tysięcznych częściach satoshi: 1000 msat = 1 sat. Ten sam publiczny QR może służyć kolejnym osobom, ale jego zeskanowanie nie potwierdza płatności. [3]
Przy withdrawRequest kierunek jest odwrotny. Anna chce wypłacić saldo z serwisu, a nie mu zapłacić. Jej portfel tworzy więc fakturę do odbioru pieniędzy, którą serwis ma opłacić. Serwis podaje identyfikator k1, adres callback oraz limity minWithdrawable i maxWithdrawable w msat; po zatwierdzeniu portfel przekazuje fakturę w pr. Odpowiedź OK oznacza przyjęcie zlecenia, nie otrzymanie pieniędzy przez Annę. Portfel nadal czeka na wpływ. Kod wypłaty może działać jak voucher dostępny każdemu, kto go posiada, więc nie publikuj go jak zwykłego kontaktu do przyjmowania płatności. [4]
W innym serwisie Anna wybiera LNURL-auth. Portfel pokazuje domenę oraz cel żądania z tag login. Za jej zgodą podpisuje jednorazowe wyzwanie k1 prywatnym kluczem przypisanym do tej domeny, linkingPrivKey. Wysyła serwisowi podpis i odpowiadający mu klucz publiczny linkingKey, który pozwala sprawdzić podpis. Nie przekazuje klucza prywatnego. Serwis może rozpoznać powracającego posiadacza klucza, ale sama weryfikacja nie ujawnia jego tożsamości poza siecią. Portfel nie wysyła serwisowi seeda, czyli początkowej tajnej wartości służącej do wyprowadzania kluczy, ani Seed Phrase, czyli słów odzyskiwania. Technicznie wykorzystuje podpis ECDSA na krzywej secp256k1. Pole action może oznaczać rejestrację, logowanie, powiązanie konta lub inną autoryzację, dlatego warto przeczytać całe potwierdzenie. Podpisanie tego wyzwania samo w sobie nie jest płatnością bitcoinową. [5]
Żądanie, odpowiedź serwisu i rzeczywisty przepływ pieniędzy to odrębne kroki. Gdy Anna traci połączenie, najpierw sprawdza pierwotną płatność w portfelu. Kolejna próba z nową fakturą może spowodować kolejną płatność. Opcjonalne LUD-21 dodaje adres verify do sprawdzania konkretnej faktury: settled true informuje o rozliczeniu, a settled false o fakturze jeszcze nierozliczonej. Samo OK nie wystarcza. Odpowiedź może zawierać preimage — pierwotną tajną wartość powiązaną z płatnością. Portfel oblicza z niej hash, czyli skrót kontrolny, i porównuje go z hashem płatności we właściwej fakturze. Dowolna tajna wartość nie wystarczy: musi pasować właśnie do tej płatności. Sprawdzenie wyniku nie zapewnia dostępności serwisu ani płynności przychodzącej, czyli możliwości skierowania pieniędzy do portfela odbiorcy. [6] [3] [4]
HTTPS chroni transmisję między portfelem a serwisem, ale nie przed samym serwisem. Ten może obserwować żądania, ich czas i powtarzające się użycie. Przy logowaniu liczy się też pełna nazwa domeny: zmiana subdomeny może dać inny linkingKey i serwis uzna użytkownika za kogoś innego. Przeniesienie się do innego portfela również nie gwarantuje odzyskania tego samego logowania, ponieważ aplikacje różnie wyprowadzają klucze. Przed ważną zmianą sprawdź odzyskiwanie dostępu do konkretnego konta. LNURL nie określa, kto trzyma klucze do bitcoinów; zależy to od portfela i serwisu. [2] [5]
Podstawowe LUD-01 zapisuje adres HTTPS lub onion w formacie Bech32. To kodowanie, a nie szyfrowanie adresu ani faktura BOLT 11. Portfel odczytuje tag bezpośrednio z linku albo wysyła zapytanie internetowe GET i rozpoznaje operację z odpowiedzi JSON. Ten format nadaje danym nazwy i strukturę, które aplikacja potrafi odczytać. Sam obraz QR nie potwierdza więc tożsamości odbiorcy. Liczą się zawartość linku oraz później wyświetlona domena, czynność i warunki. [2]
Przy płatności metadata jest ciągiem tekstowym zawierającym tablicę JSON. Musi zawierać opis text/plain; pozostałe typy są opcjonalne. Portfel powinien pokazać opis razem z domeną i kwotą, aby użytkownik wiedział, na co się zgadza. Podstawowe LNURL interpretuje treść JSON odpowiedzi, a nie sam kod statusu HTTP. Dostępny serwer nie musi więc oznaczać udanego żądania: odpowiedź może zawierać ERROR. Podobnie faktura otrzymana w pr nie jest jeszcze opłacona. Aplikacja nie powinna sprowadzać tych różnych informacji do jednego zielonego znaczka. [2] [3]
Pełniejszy obraz uzyskasz, czytając to hasło razem z BOLT 11, BOLT 12, Lightning Network, Lightning Address, Prywatność w Bitcoinie, Satoshi. Do tego hasła prowadzą również odsyłacze z BOLT 12, Lightning Address, Confirmo.