BOLT 12 je protokol pro dohodnutí platby přes Lightning Network. Rozlišuje nabídku offer, žádost invoice_request a výslednou fakturu invoice. Nabídka může zůstat zveřejněná pro více plateb, zatímco konkrétní faktura obsahuje podmínky právě sjednávané platby.
Představte si kavárnu, která chce mít na pultu jeden kód pro dobrovolné příspěvky. U běžné faktury BOLT 11 by opakované placení stejného požadavku přinášelo problémy. BOLT 12 místo toho zveřejní nabídku offer. Zákazníkova peněženka podle ní pošle invoice_request, žádost o vlastní fakturu, a příjemce odpoví novou invoice. Teprve tu lze zaplatit. Jeden vytištěný QR tak může sloužit více lidem, aniž by všichni používali tutéž fakturu. Získat fakturu, třeba pomocí funkce fetchinvoice, stále neznamená poslat peníze. Nabídka také sama nedává kavárně právo strhávat další platby z cizí peněženky. [1] [3] [4]
Nabídka může popisovat cenu v bitcoinu, ale také v jiné měně. Pole offer_currency používá označení ISO 4217; například částka v USD je uvedena v centech. Při vystavení faktury se může zohlednit počet kusů a přepočet měny. Konečná bitcoinová invoice_amount je však v millisatoshi, tedy tisícinách satoshi: 1000 msat = 1 sat. Právě tuto částku a poplatek potřebuje plátce znát před zaplacením, nejen původní cedulku s cenou. Pokud žádost obsahuje přesnou invreq_amount, faktura musí mít stejnou částku. Jinak peněženka kontroluje, zda výsledek zapadá do povoleného rozsahu; při odchylce si má vyžádat nové schválení. Přepočet nemá být neviditelným souhlasem s libovolnou cenou. [1] [3]
Vytištěný kód může zůstat na pultu, ale i nabídka může mít konec platnosti, zapsaný jako offer_absolute_expiry. Každá vystavená faktura má navíc vlastní čas vytvoření invoice_created_at a dobu platnosti invoice_relative_expiry. Pokud tato doba chybí, platí výchozích 7200 sekund, tedy dvě hodiny. Starou fakturu proto nelze zaměnit za trvale platný kontakt. Peněženky také musejí rozumět povinným funkcím uvedeným ve zprávách. Neznámý sudý bit značí povinnou funkci a vede k odmítnutí; neznámý lichý je volitelný a lze jej ignorovat. Důvodem je bezpečná kompatibilita, nikoli chyba, kterou by měl uživatel obejít ručním přepisováním kódu. [1]
Po zaplacení si uchovejte fakturu a výsledek z peněženky. K důkazům vypořádání patří také preimage, tajná hodnota získaná při dokončení platby. Peněženka z ní vypočítá hash, tedy kontrolní údaj, a porovná ho s platebním hashem ve faktuře. Spolu s fakturou tak lze doložit její zaplacení, nikoli však samo o sobě určit, který člověk platil. Pokud se aplikace odpojí nebo ztratí odpověď, nejprve zkontrolujte stav předchozí platby; nová faktura může vést k další platbě. Stejně opatrně čtěte sliby o opakovaných platbách. Podpora BOLT 12 automaticky neznamená podporu každého rozšíření ani svolení k automatickému inkasu. Zvlášť ověřte, zda peněženka umí přijímat platby pomocí nabídek, zda umí zaplatit z cizí nabídky a co jste dovolili připojené aplikaci. [1] [3]
Vyžádání faktury a samotný převod používají síť pro jiné účely. offer_paths určuje cestu zprávy s žádostí, kdežto invoice_paths nabízí cesty pro platbu. BOLT 12 používá blinded paths, tedy trasy, které skrývají část informací o spojení k příjemci. Méně zveřejněných údajů o síti pomáhá soukromí, není to však slib úplné anonymity. Ani skrytá cesta nezaručuje dostupného příjemce nebo likviditu, tedy dost peněz na potřebných stranách platebních kanálů. Technicky musí současná invoice obsahovat tyto cesty i odpovídající invoice_blindedpay s platebními parametry, a to i pro cestu vedoucí přímo k příjemci. K vyžádání faktury přitom není potřeba běžný platební server HTTPS. [1] [2]
Když chce obchodník vrátit zákazníkovi peníze, směr jednání se obrátí. Ten, kdo chce platit, může zveřejnit invoice_request bez předchozí offer. Zákazník jako budoucí příjemce odpoví vlastní invoice, kterou obchodník zaplatí. Nejde o vymazání nebo odvolání původní platby, ale o novou platbu opačným směrem. Obchodník si musí ověřit, že faktura patří zamýšlenému příjemci; někdy to vyžaduje domluvu mimo protokol. Naskenovaná žádost sama neprokazuje nárok na refundaci ani neschvaluje převod peněz. Technický postup usnadňuje komunikaci, nenahrazuje dohodu, komu se má vracet. [1]
BOLT 12 ukládá údaje jako TLV: každé pole uvádí svůj typ, délku a hodnotu. Nabídka v textové podobě začíná lno, žádost lnr. Použitá znaková sada připomíná Bech32, ale chybí jeho koncový kontrolní součet. To ještě neříká nic o tom, kdo smí dostat zaplaceno. Samotná offer není podepsaná. Pomocí digitálních podpisů BIP340 Schnorr se ověřuje faktura a běžná žádost, která odpovídá na nabídku. Samostatná žádost zveřejněná bez nabídky, například pro vrácení peněz, podpis neobsahuje. Podpis se váže na kořen Merkle struktury: společný kontrolní údaj vypočítaný z příslušných polí. Lze tak dokazovat vybraná pole, aniž by se vždy zveřejnily všechny podrobnosti. Neznamená to možnost přepsat podepsané podmínky ani důkaz občanské totožnosti obchodníka. [1]
Peněženka musí poznat, že dostala odpověď na svou žádost, ne jen nějakou platně podepsanou fakturu. Proto porovnává převzatá pole invoice_request s invoice, síť, částku a podpis. Veřejný klíč invoice_node_id má odpovídat offer_issuer_id; pokud nabídka používá příslušnou skrytou cestu bez tohoto identifikátoru, kontroluje se její koncový blinded_node_id. Je to podobné jako zkontrolovat, zda účet patří k vašemu stolu, ne pouze zda na něm je pravé razítko. Merkle struktura umožňuje prokázat vybrané údaje, ale nezbavuje peněženku povinnosti ověřit celé podmínky potřebné k platbě. Cizí platná faktura se nestává správnou jen proto, že projde kontrolou podpisu. [1]
Pro nejúplnější obraz čtěte toto heslo společně s BOLT 11, Lightning Network, Lightning Routing, Soukromí v Bitcoinu, Satoshi, LNURL. Opačným směrem na něj odkazují také BOLT 11, LNURL, Just-in-Time Channels.