Rusty Russell je open-source vývojář, který zásadně přispěl ke Core Lightning, programu pro provoz uzlu Lightning Network. Pomáhal také vytvářet společné specifikace BOLT a dlouhodobě prosazoval BOLT 12, umožňující získávat nové platební požadavky ze znovupoužitelné nabídky. Lightning je síť pro bitcoinové platby prostřednictvím platebních kanálů.
Velké projekty často začínají nenápadně. Retrospektiva Blockstream z 9. června 2026 připomíná Russellův první commit z 26. května 2015: malý nástroj pro sestavení zprávy otevírající kanál. Commit je zaznamenaná změna v historii kódu. Z raného pokusu postupně vyrostl Core Lightning a Russell se podílel na jeho programu, testech i vedení dalších vývojářů. Článek zároveň popisuje jeho odchod po jedenácti letech. Není to oznámení konce všech budoucích open-source příspěvků ani důvod považovat někdejší vedoucí roli za trvalou moc nad celou sítí. [1]
Představte si kavárnu a zákazníka, kteří používají odlišné programy. Platba nemá záviset na tom, zda si vybrali stejného výrobce. Potřebují společná pravidla zpráv a jejich významu. Tuto úlohu mají specifikace BOLT, dokumenty popisující komunikaci v Lightningu. Russell vedl jejich společný vývojový proces a podporoval interoperabilitu, tedy schopnost různých implementací spolupracovat. Veřejný repozitář přijímá návrhy i připomínky. Ani významný autor však sám nemůže vnutit změnu všem uzlům: společná pravidla se musí promítnout do skutečného softwaru a jeho používání. [1] [2]
Dva programy mohou stejnému odstavci rozumět odlišně. Russellův lnprototest nabízí pomocné nástroje v jazyce Python, s nimiž lze psát scénáře a zkoušet reakce na zprávy protokolu. README, úvodní dokumentace projektu, odlišuje dummy runner neboli zkušební napodobeninu od běhu proti skutečné implementaci. Simulace je užitečná pro přípravu testu, ale její úspěch sám neprokazuje chování reálného uzlu. Důležité je vědět, co se skutečně spustilo a které situace test pokryl. Ani úspěšná sada scénářů není úplným auditem každé možné chyby. [3]
Kavárna může podle BOLT 12 zveřejnit znovupoužitelnou nabídku, třeba jako QR kód. Zákazníkova peněženka z ní pošle žádost invoice_request a získá konkrétní fakturu, tedy platební požadavek s údaji pro danou úhradu. Teprve podle něj se platí. Nabídku tak mohou zákazníci používat opakovaně a dostávat jednotlivé faktury. Neznamená to, že lze jednu již použitou fakturu vydávat za nový požadavek při každém nákupu. Oddělení nabídky, žádosti a faktury umožňuje pohodlné placení bez záměny jednotlivých plateb. [4]
Toto rozdělení je vidět i v Core Lightning. Příkaz fetchinvoice kontaktuje vydavatele nabídky a získá fakturu. V položce changes může uvést rozdíly, například změnu popisu nebo částky proti nabídce. Úspěšná odpověď neznamená odeslání peněz. Je to podobné jako obdržet účet v kavárně: nejprve si ověříte, za co a kolik se má platit. Peněženka musí vrácené podmínky zpracovat a platbu zahájit zvlášť. Člověk pak nemá zaměňovat dokončené načtení požadavku s dokončenou úhradou. [5]
Dokumentace rozhraní pay rozlišuje complete, pending a failed: dokončeno, čeká se a neúspěch. Čekající stav není potvrzením úhrady. Rozlišuje také amount_msat, částku pro příjemce, a amount_sent_msat, celkově odeslanou částku včetně poplatků. Zkratka msat znamená millisatoshi, tisícinu satoshi. Zákazník tedy může zaplatit o poplatek více, než kavárna dostane. Dokumentace už pay označuje jako zastarávající rozhraní a uvádí přechod na xpay; jde zde o vysvětlení stavů a částek, ne návod k instalaci určité verze. Výsledek vždy čtěte podle skutečně používaného programu. [6]
Když kavárna vrací peníze, původní platba se nepřetočí zpátky. BOLT 12 popisuje i opačný tok: obchodník oznámí částku, kterou chce poslat, zákazník poskytne fakturu a obchodník ověří invoice_node_id, identifikátor uzlu, kterému má platit. Následuje nová platba směrem k zákazníkovi. Nejde o zrušení původního převodu ani automatický nárok na refundaci. Protokol poskytuje způsob provedení; o důvodu a podmínkách vrácení peněz se musí účastníci domluvit samostatně. [4]
Při sporu je užitečné vědět, co důkaz vlastně potvrzuje. BOLT 12 vysvětluje, že preimage, tajná hodnota odpovídající otisku v platebním požadavku, může doložit zaplacení faktury. Jakmile je však zveřejněna, může ji ukázat i někdo jiný; sama neprokazuje, kdo peníze odeslal. Klíč vložený do žádosti umožňuje doložit, kdo o fakturu požádal. Tím se ale automaticky neověřuje občanská identita člověka. Zaplacená faktura, kontrola klíče a totožnost zákazníka jsou různé informace, i když v běžné řeči splývají. [4]
Pro nejúplnější obraz čtěte toto heslo společně s Andrew Poelstra, Tadge Dryja, Lightning Network. Opačným směrem na něj odkazují také Andrew Poelstra, Tadge Dryja.