167 / 736LNADDR

Lightning Address

Zapamatovatelné jméno pro platby přes Lightning

Lightning Address vypadá jako e-mail, ale slouží k získání platební žádosti přes Lightning. Co se za jménem děje a co si před odesláním ověřit.

Lightning Address je čitelné jméno ve tvaru uživatel@doména, přes které podporovaná peněženka získá žádost o platbu v Lightning Network. Lightning slouží k rychlým bitcoinovým platbám; jeho faktura je platební požadavek s údaji, podle kterých může peněženka zaplatit. Jméno můžete používat opakovaně, ale peněženka pro jednotlivou platbu vyžádá konkrétní fakturu BOLT 11. Nejde o e-mailovou schránku ani o bitcoinovou adresu pro platbu přímo na blockchainu.

Anna chce přijímat příspěvky za svůj podcast. Místo posílání nové dlouhé faktury každému posluchači zveřejní Lightning Address. Ilustrační anna@example.com se snadno zapamatuje: část před zavináčem označuje příjemce u dané služby a část za ním doménu, která peněžence odpoví. Podobnost s e-mailem je záměrná, peníze se ale poštou neposílají. Existující e-mail automaticky není Lightning Address a samotné jméno neprokazuje, komu patří. Před příspěvkem proto ověřte adresu u autora, kterého chcete podpořit. [1] [6]

Posluchač vloží jméno do podporované peněženky. Ta od služby zjistí popis platby a povolené rozmezí částek. Až uživatel zkontroluje doménu, popis a zvolenou částku, vyžádá peněženka konkrétní fakturu BOLT 11 a ověří její částku před zaplacením. Získat fakturu ještě neznamená zaplatit. Tento postup se jmenuje LNURL-pay. Služba pro něj vrací callback, adresu pro vyžádání faktury, metadata s popisem a meze minSendable a maxSendable. Částka amount se předává v msat, tedy tisícinách jednotky satoshi: 1000 msat = 1 sat. Faktura přijde v poli pr. [2] [3]

Anna může mít jméno u služby, která za ni spravuje peněženku, nebo ho napojit na vlastní Lightning uzel, program zajišťující její platby. Vzhled adresy rozdíl neprozradí. Webový endpoint, tedy místo, kde server odpovídá peněžence, může přes pomocný bridge server vyžádat fakturu od jejího uzlu. Takový prostředník není automaticky správcem peněz, záleží na uspořádání a udělených oprávněních. Kontrola nad odpověďmi serveru je přesto důležitá: kdo je může podvrhnout, může nabídnout plátci jinou fakturu. Vlastní doména sama o sobě nezaručuje self-custody, tedy vlastní správu klíčů. [3] [4]

Peněženka může umět odeslat platbu na Lightning Address, aniž by uživateli poskytovala jeho vlastní adresu pro příjem. Příjem navíc vyžaduje dostupnou webovou službu, vystavení faktury a možnost platbu v Lightning Network skutečně přijmout. Platby procházejí kanály: spojeními mezi účastníky, v nichž se mění rozdělení prostředků mezi obě strany. Sem patří i Inbound Liquidity, příchozí likvidita: prostředky na protější straně kanálů, které se při platbě mohou přesunout k příjemci. Zapamatovatelné jméno ji nevytvoří. Pokud se adresa načte, ale platba selže, nemusí být chyba ve jménu. Rozlišujte odpověď webu, získání faktury a potvrzený příjem peněz. [3] [5]

Na vlastní doméně můžete změnit, který server obsluhuje platby, a jméno pro posluchače zachovat. Dokumentace BTCPay ukazuje přesměrování endpointu pomocí HTTP 301: webový požadavek se pošle jinam, žádné bitcoiny se tím nepřevedou. U jména na cizí doméně takovou kontrolu mít nemusíte. Seed Phrase, obnovovací slova peněženky, sama o sobě nezaručuje obnovení přístupu k účtu služby. Nezálohuje ani správu domény a nastavení DNS, systému určujícího, kam doména vede. Po změně ověřte nejen otevření adresy, ale i správnou fakturu a skutečně přijatou zkušební platbu. Staré kontakty se samy o novém jménu nedozvědí. [5] [3]

Pravidla LUD-16 popisují převod jména na webový požadavek GET, tedy žádost o data. Peněženka osloví doménu na cestě /.well-known/lnurlp/username, kde username nahradí uživatelským jménem. Na běžném webu používá HTTPS, u onion domény HTTP. Odpověď typu payRequest navazuje na LUD-06. HTTPS chrání přenos před podvržením po cestě, nedokazuje však poctivost samotné služby. Ta zpracovává dotazy a ví, pro kterého příjemce vystavuje fakturu; čitelné jméno tedy samo nepřidává anonymitu. [1] [2]

LUD-16 pro uživatelské jméno připouští malá písmena a-z, číslice 0-9 a znaky -_.; běžný e-mail může mít širší sadu znaků. Volitelná zkratka @domain označuje výchozího příjemce _@domain na cestě /.well-known/lnurlp/_; peněženka nebo služba ji nemusí podporovat. Ani doplněk +tag není univerzální. Pokud ho služba podporuje, může rozlišovat účel příspěvku a uvést ho jako text/tag. Doplněk není nový soukromý klíč ani záruka soukromí. Pro běžné použití je nejspolehlivější převzít přesné jméno, které příjemce zveřejnil. [1]

Metadata jsou doprovodné údaje, které si peněženka a služba předávají ve strukturovaném formátu JSON. V LNURL-pay obsahují text/plain, stručný popis platby. LUD-16 přidává text/identifier pro vazbu ke jménu, nebo text/email, pokud jméno odpovídá skutečné e-mailové adrese. To pomáhá peněžence ukázat, k čemu se platba vztahuje. Pořád jde ale o údaje dodané službou, nikoli o nezávislé ověření občanské identity Anny. Kontrola původně získané adresy, domény a částky proto zůstává součástí rozumného placení. [1] [2]

Pro nejúplnější obraz čtěte toto heslo společně s LNURL, BOLT 11, Lightning Network, Inbound Liquidity, Vlastní úschova, Soukromí v Bitcoinu. Opačným směrem na něj odkazují také LNURL, Inbound Liquidity, Confirmo, Strike.

DOC · 001Lightning Address — LUD-16Specifikace DOC · 002LNURL — LUD-06 payRequestSpecifikace DOC · 003Lightning Address — Implementation guideDokumentace DOC · 004Lightning Address — Bridge serverDokumentace DOC · 005BTCPay Server — Address redirectionDokumentace DOC · 006Lightning Address — Project overviewPrimární zdroj
Revidováno: Primární zdroje · Nejde o investiční doporučení