BOLT 11

Anna si kupuje elektronickou knihu. Obchod jí místo čísla účtu zobrazí Lightning fakturu a její peněženka z ní přečte platební údaje. Anna nemusí rozumět dlouhému řetězci: před potvrzením si zkontroluje částku, účel a poplatek. Některé faktury částku neobsahují, například při dobrovolném příspěvku. Pak ji zadává plátce; prázdná částka neznamená nulovou platbu. Pro zvídavější: lnbc na začátku označuje hlavní síť, lntb testnet, lntbs signet a lnbcrt regtest, tedy testovací prostředí. Zakódovaná částka je v BTC s případným násobitelem m, u, n nebo p, nikoli přímo v satoshi. U p musí končit číslicí 0, aby odpovídala celým millisatoshi: 1000 msat = 1 sat. [1]

Popis má spojit technický požadavek s lidským důvodem platby, třeba s Anninou knihou. Faktura obsahuje buď samotný text v poli d, nebo jeho digitální otisk v poli h. Tento otisk vzniká funkcí SHA256; peněženka má ověřit, že zvlášť dodaný popis dává stejný výsledek. Takovému krátkému kontrolnímu údaji vypočítanému z textu se říká hash. Z pouhého otisku se obsah objednávky vyčíst nedá. Správný podpis chrání vazbu popisu na klíč příjemce, ale neslibuje, že obchodník knihu skutečně dodá. Pro tvůrce aplikací platí ještě jedno pravidlo: popis je cizí text, který se bezpečně zobrazuje jako data, nikdy se nespouští jako kód. [1]

Anna si nechá objednávku otevřenou a vrátí se později. Peněženka může oznámit, že faktura vypršela; v takovém případě si má vyžádat novou. Konec platnosti se počítá z času vytvoření timestamp a doby x. Když x chybí, výchozí doba je 3600 sekund, tedy hodina. Vypršení nevrací již dokončenou platbu. Jinou věc řeší pole c, technicky min_final_cltv_expiry_delta: časovou rezervu poslední podmíněné platby HTLC na trase. HTLC drží platbu pod podmínkou doložení správného tajemství včas. Rezerva se měří v blocích, nikoli v sekundách platnosti faktury; bez c plátce použije alespoň 18 bloků. Tyto dva časové údaje se nesmějí zaměňovat. [1]

Lightning platba prochází platebními kanály. V kanálu si dvě strany průběžně upravují rozdělení prostředků, aniž by každou běžnou platbu zapisovaly do hlavního bitcoinového blockchainu. Aby platba dorazila, potřebuje průchozí trasu a dostatek prostředků na správných stranách kanálů, tedy likviditu. Faktura může přidat routing hints: nápovědy pro poslední úsek cesty v poli r. Pomáhají najít příjemce, ale nejsou živým přehledem jeho dostupné kapacity. Mohou také odhalit veřejné klíče uzlů, identifikátory kanálů a poplatkové parametry; celou fakturu proto nepovažujte za soukromý dokument. Volitelné pole f může nabídnout běžnou bitcoinovou adresu jako náhradní možnost. Platba na ni už jde po hlavním řetězci, má vlastní poplatky a čeká na potvrzení. Není to pouhé jiné tlačítko pro stejný způsob doručení. [1] [2] [5]

Naskenovaný QR kód ani přijatá faktura nejsou účtenkou. Po odeslání sledujte výsledek v peněžence: čekající platba se liší od dokončené. Úspěšné vypořádání dokládá také správný preimage, tajná hodnota, jejíž hash musí odpovídat platebnímu hashi ve faktuře. Fakturu a tento údaj lze uchovat jako podklady k platbě, nikoli však jako záruku dodání zboží. Když se aplikace odpojí nebo ztratí odpověď, nejprve ověřte stav původní platby. Vystavit hned novou fakturu nebo zaplatit náhradní adresu může znamenat zaplatit znovu. Některé peněženky opakovaný pokus rozpoznají, samotný formát ale neposkytuje univerzální ochranu napříč aplikacemi a platebními cestami. [2] [4]

Dlouhý řetězec používá kódování Bech32. Jeho kontrolní součet pomáhá zachytit chybu přepisu; není šifrováním a obsah neskrývá. Jinou úlohu má digitální podpis ECDSA na křivce secp256k1: umožňuje ověřit, že platební údaje odpovídají klíči příjemce a nebyly dodatečně změněny. Nepotvrzuje občanskou totožnost ani poctivost člověka za klíčem. Na rozdíl od bitcoinových adres Bech32 může BOLT 11 překročit 90 znaků. Pro QR se hodí velká písmena; platný řetězec však nesmí míchat velká a malá. Člověk obvykle používá skenování nebo kopírování, zatímco tyto kontroly provádí jeho peněženka. [1]

Payment hash je digitální otisk tajné hodnoty payment preimage, vypočtený funkcí SHA256 a uložený v poli p. Při úspěšném vypořádání se plátce dozví preimage a může ověřit, že otisk souhlasí. Pole s naproti tomu obsahuje payment_secret. Tento údaj plátce přečte už z faktury a předává jej příjemci v poslední části směrované platby; pomáhá chránit příjemce před sondováním zprostředkujícími uzly. Secret není preimage ani seed peněženky. Jeho znalost z QR tedy není důkazem zaplacení a neopravňuje k obnově peněženky. Aktuální BOLT 11 vyžaduje obě pole p a s. Podobně znějící názvy zakrývají rozdílné úkoly: rozpoznat platbu, předat potřebný údaj a doložit vypořádání. [1] [2]

Peněženky potřebují vědět i to, zda konkrétní platbu umějí provést. Pole 9 nese příznaky funkcí. Neznámý sudý bit znamená povinnou funkci, bez které se platba odmítne; neznámý lichý je volitelný a lze ho ignorovat. Splněny musí být také známé závislosti mezi funkcemi. Příkladem je Basic MPP, rozdělení jedné platby do více částí, které se u příjemce spojí. Použít se smí jen tehdy, když faktura nabízí basic_mpp. Z rozdělení nevzniká několik samostatných faktur ani důvod zaplatit každou část znovu. Pro začátečníka je praktický závěr prostý: hlášení o nepodporované funkci se nemá obcházet ruční úpravou faktury; nejprve se řeší kompatibilita peněženek. [1] [3]