Lightning Address

Anna chce otrzymywać wpłaty na swój podcast. Zamiast wysyłać każdemu słuchaczowi nową długą fakturę, publikuje Lightning Address. Przykładowe anna@example.com łatwo zapamiętać: przed znakiem @ jest odbiorca w danej usłudze, a za nim domena odpowiadająca portfelowi. Podobieństwo do poczty jest celowe, ale pieniądze nie są wysyłane e-mailem. Istniejący e-mail nie staje się automatycznie Lightning Address, a sama nazwa nie dowodzi, do kogo należy. Sprawdź ją u twórcy, którego chcesz wesprzeć. [1] [6]

Słuchacz wpisuje nazwę w zgodnym portfelu. Portfel pobiera z usługi opis i dozwolony zakres kwot. Gdy użytkownik sprawdzi domenę, opis i wybraną kwotę, portfel prosi o konkretną fakturę BOLT 11 i kontroluje jej kwotę przed zapłatą. Pobranie faktury nie jest jeszcze płatnością. Ten proces to LNURL-pay. Usługa zwraca callback, adres do żądania faktury, opisowe metadata oraz granice minSendable i maxSendable. amount podaje się w msat, tysięcznych częściach satoshi: 1000 msat = 1 sat. Faktura przychodzi w polu pr. [2] [3]

Anna może korzystać z usługi zarządzającej jej portfelem albo podłączyć nazwę do własnego węzła Lightning, programu obsługującego jej płatności. Wygląd adresu nie zdradza różnicy. Webowy endpoint, miejsce odpowiedzi serwera na zapytania portfela, może przez serwer pośredniczący poprosić jej węzeł o fakturę. Pośrednik nie musi przechowywać środków; zależy to od konfiguracji i uprawnień. Kontrola odpowiedzi jest jednak ważna: kto może je podmienić, może przedstawić płacącemu inną fakturę. Własna domena sama nie gwarantuje self-custody, czyli samodzielnej kontroli nad kluczami. [3] [4]

Portfel może wysyłać na Lightning Address, nie dając użytkownikowi własnego adresu odbiorczego. Odbiór wymaga też dostępnej usługi internetowej, wystawienia faktury i możliwości przyjęcia płatności w Lightning Network. Płatności przechodzą przez kanały: połączenia między uczestnikami, w których zmienia się podział środków między obie strony. Potrzebna jest między innymi Inbound Liquidity: środki po drugiej stronie kanałów, które podczas płatności mogą przejść do odbiorcy. Łatwa nazwa nie tworzy tej płynności. Jeśli adres się wczytuje, ale płatność nie dochodzi do skutku, problem nie musi leżeć w nazwie. Odróżniaj odpowiedź strony, pobraną fakturę i potwierdzony wpływ pieniędzy. [3] [5]

Na własnej domenie możesz zmienić serwer obsługujący płatności, zachowując nazwę znaną słuchaczom. Dokumentacja BTCPay pokazuje przekierowanie endpointu przez HTTP 301: żądanie trafia gdzie indziej, lecz monety się nie przemieszczają. Przy nazwie na cudzej domenie możesz nie mieć takiej kontroli. Seed Phrase, słowa odzyskiwania portfela, sama w sobie nie gwarantuje odzyskania dostępu do konta w usłudze. Nie jest też kopią dostępu do administracji domeną ani ustawień DNS, systemu wskazującego, dokąd prowadzi domena. Po zmianie sprawdź prawidłową fakturę i rzeczywisty odbiór próbnej płatności, nie tylko otwarcie adresu. Dawne kontakty nie poznają nowej nazwy automatycznie. [5] [3]

LUD-16 opisuje zamianę nazwy na żądanie GET, czyli prośbę o dane. Portfel odpytuje domenę pod ścieżką /.well-known/lnurlp/username, zastępując username nazwą użytkownika. W zwykłej sieci używa HTTPS, a dla domeny onion — HTTP. Odpowiedź payRequest prowadzi dalej według LUD-06. HTTPS chroni połączenie przed podmianą danych w drodze, ale nie dowodzi uczciwości samej usługi. Ta przetwarza zapytania i wie, dla którego odbiorcy wystawia fakturę. Czytelna nazwa sama nie zapewnia zatem anonimowości. [1] [2]

LUD-16 dopuszcza w nazwie małe litery a-z, cyfry 0-9 i -_.; zwykły e-mail pozwala na więcej znaków. Opcjonalny skrót @domain wskazuje domyślnego odbiorcę _@domain pod ścieżką /.well-known/lnurlp/_, lecz portfel albo usługa nie muszą go obsługiwać. Dodatek +tag też nie jest uniwersalny. Obsługująca go usługa może rozróżniać cel wpłaty i podawać go jako text/tag. To nie nowy klucz prywatny ani gwarancja prywatności. Na co dzień najlepiej skopiować dokładną nazwę opublikowaną przez odbiorcę. [1]

Metadane to dodatkowe informacje wymieniane między portfelem a usługą w uporządkowanym formacie JSON. W LNURL-pay obejmują text/plain, krótki opis płatności. LUD-16 dodaje text/identifier wiążący płatność z nazwą albo text/email, gdy nazwa odpowiada rzeczywistemu adresowi e-mail. Portfel może dzięki temu pokazać, czego dotyczy płatność. Nadal są to informacje od usługi, a nie niezależne potwierdzenie rzeczywistej tożsamości Anny. Dlatego warto sprawdzać pierwotnie uzyskany adres, domenę i kwotę. [1] [2]