LNURL je rodina postupů, kterými si Lightning peněženka a webová služba předají údaje potřebné k určitému úkolu. 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. Peněženka z odkazu zjistí, zda má připravit platbu, přijmout peníze ze služby nebo potvrdit přihlášení. Samotný odkaz ještě není fakturou ani důkazem, že peníze dorazily.
Představte si Annu, která nejprve načte QR pro příspěvek autorovi, potom kód pro vyzvednutí poukazu a nakonec kód pro přihlášení na web. Telefon používá stejně, ale pokaždé schvaluje něco jiného. LNURL tyto úkoly rozlišuje: payRequest znamená placení, withdrawRequest výběr a login přihlášení. Jednotlivé postupy popisují dokumenty LUD. Jsou to volitelná pravidla pro spolupráci aplikací, nikoli změna pravidel Bitcoinu. Podpora jednoho postupu v peněžence neznamená, že umí všechny ostatní. [1] [7]
U platby typu payRequest vrátí služba popis a rozmezí částek. Anna zkontroluje doménu, tedy název služby v její webové adrese, přečte si popis a zvolí příspěvek. Teprve po schválení podmínek si peněženka vyžádá konkrétní Lightning fakturu BOLT 11 a před zaplacením porovná její částku se zvolenou hodnotou. Technicky používá adresu callback, limity minSendable a maxSendable a popis metadata; částku posílá jako amount a fakturu dostane v poli pr. Částky jsou v msat, tisícinách satoshi: 1000 msat = 1 sat. Stejný veřejný QR může sloužit dalším lidem, ale jeho načtení není potvrzením platby. [3]
Při withdrawRequest je směr opačný. Anna nechce platit službě, chce z ní vybrat zůstatek. Její peněženka proto vytvoří vlastní příjmovou fakturu a služba ji má zaplatit. Služba předá identifikátor k1, adresu callback a limity minWithdrawable a maxWithdrawable v msat; peněženka po souhlasu vrátí fakturu v poli pr. Odpověď OK znamená, že služba požadavek přijala, ne že už Anna peníze dostala. Peněženka stále čeká na skutečný příjem. Výběrový kód může fungovat jako poukaz pro toho, kdo ho drží, proto ho nezveřejňujte jako běžný kontakt pro příjem plateb. [4]
Na jiném webu Anna zvolí LNURL-auth. Peněženka ukáže doménu a účel požadavku s tag login. Po jejím souhlasu podepíše jednorázovou výzvu k1 soukromým klíčem určeným pro tuto doménu, linkingPrivKey. Službě odešle podpis a odpovídající veřejný klíč linkingKey, kterým lze podpis ověřit. Soukromý klíč jí nepředává. Služba tak pozná vracejícího se držitele klíče, ale samotné ověření neodhalí jeho skutečnou totožnost. Peněženka neposílá službě seed, tajný výchozí údaj pro odvození klíčů, ani Seed Phrase, tedy obnovovací slova. Technicky jde o podpis ECDSA na křivce secp256k1. Pole action může označovat registraci, přihlášení, propojení účtu nebo jinou autorizaci, proto má smysl číst celé potvrzení. Podpis této výzvy sám není bitcoinovou platbou. [5]
Požadavek, odpověď služby a skutečný přesun peněz jsou různé kroky. Když Anna ztratí připojení, nejprve zkontroluje původní platbu v peněžence. Nový pokus s novou fakturou může způsobit další platbu. Volitelné LUD-21 přidává adresu verify pro kontrolu konkrétní faktury: settled true znamená hlášené vypořádání, settled false dosud nevypořádanou fakturu. Samotné OK nestačí. Odpověď může obsahovat preimage, původní tajnou hodnotu spojenou s platbou. Peněženka z ní vypočítá hash, kontrolní údaj, a porovná ho s platebním hashem ve správné faktuře. Nestačí tedy obdržet libovolnou tajnou hodnotu: musí odpovídat právě této platbě. Kontrola výsledku ale nezajistí dostupnou službu ani příjmovou likviditu, tedy možnost směrovat peníze do cílové peněženky. [6] [3] [4]
HTTPS chrání přenos mezi peněženkou a službou, nikoli před samotnou službou. Ta může sledovat požadavky, jejich čas a opakované použití. U přihlášení navíc rozhoduje celý název domény: změna subdomény může vytvořit jiný linkingKey a web pak člověka považuje za jiného uživatele. Ani přechod do jiné peněženky nemusí obnovit stejné přihlášení, protože aplikace používají různé způsoby odvození klíčů. Před důležitou změnou si proto ověřte obnovu přístupu ke konkrétnímu účtu. LNURL samo neříká, kdo drží klíče k bitcoinům; to závisí na použité peněžence a službě. [2] [5]
Základní LUD-01 zapisuje HTTPS nebo onion URL ve formátu Bech32. Je to kódování, nikoli šifrování adresy a nikoli faktura BOLT 11. Peněženka přečte tag přímo z odkazu, nebo odešle GET, webový požadavek na data, a typ operace zjistí z odpovědi ve formátu JSON. Tento formát dává údajům názvy a strukturu, aby je aplikace uměla přečíst. Obrázek QR proto sám nepotvrzuje totožnost příjemce. Rozhoduje obsah odkazu a následně zobrazená doména, úkol a podmínky. [2]
V postupu placení jsou metadata textový řetězec obsahující JSON pole. Musí v něm být položka text/plain s popisem; další typy jsou volitelné. Peněženka má popis ukázat spolu s doménou a částkou, aby člověk věděl, co schvaluje. Základní LNURL vykládá JSON tělo odpovědi, nikoli samotný HTTP stavový kód. Dostupný server tedy ještě nemusí znamenat úspěšný požadavek: uvnitř odpovědi může být ERROR. A ani faktura přijatá v poli pr ještě není zaplacená. To jsou různé informace, které by aplikace neměla slévat do jedné zelené značky. [2] [3]
Pro nejúplnější obraz čtěte toto heslo společně s BOLT 11, BOLT 12, Lightning Network, Lightning Address, Soukromí v Bitcoinu, Satoshi. Opačným směrem na něj odkazují také BOLT 12, Lightning Address, Confirmo.