Rusty Russell to programista open source, który znacząco przyczynił się do rozwoju Core Lightning, programu do obsługi węzła Lightning Network. Pracował też nad wspólnymi specyfikacjami BOLT i promował BOLT 12, pozwalający pobierać nowe żądania płatności z oferty wielokrotnego użytku. Lightning przesyła płatności w bitcoinie przez kanały płatnicze.
Duże projekty często zaczynają się niepozornie. Podsumowanie Blockstream z 9 czerwca 2026 roku przypomina pierwszy commit Russella z 26 maja 2015 roku: małe narzędzie do tworzenia komunikatu otwierającego kanał. Commit zapisuje zmianę w historii kodu. Z wczesnego eksperymentu powstał Core Lightning, a Russell rozwijał program, testy i umiejętności innych programistów. Artykuł opisuje również jego odejście po jedenastu latach. Nie ogłasza końca wszystkich przyszłych wkładów w open source ani nie zmienia dawnej roli lidera w trwałą władzę nad siecią. [1]
Wyobraź sobie kawiarnię i klienta używających różnych programów. Płatność nie powinna wymagać wyboru tego samego dostawcy. Potrzebne są wspólne zasady dotyczące komunikatów i ich znaczenia. Tę komunikację w Lightning opisują specyfikacje BOLT. Russell koordynował proces ich wspólnego tworzenia i wspierał interoperacyjność, czyli zdolność różnych implementacji do współpracy. Publiczne repozytorium przyjmuje propozycje i uwagi. Nawet ważny współtwórca nie może sam narzucić zmiany wszystkim węzłom: reguły muszą trafić do rzeczywistego oprogramowania i praktycznego użycia. [1] [2]
Dwa programy mogą różnie zrozumieć ten sam akapit. Stworzony przez Russella lnprototest udostępnia narzędzia w języku Python do pisania scenariuszy i badania reakcji na komunikaty protokołu. README, dokument wprowadzający do projektu, odróżnia wykonawcę symulacyjnego od testów rzeczywistej implementacji. Symulacja pomaga przygotować test, ale jej powodzenie nie dowodzi zachowania prawdziwego węzła. Ważne jest, co rzeczywiście uruchomiono i jakie sytuacje sprawdzono. Nawet zaliczony zestaw scenariuszy nie stanowi pełnego audytu wszystkich możliwych błędów. [3]
W BOLT 12 kawiarnia może opublikować ofertę wielokrotnego użytku, choćby jako kod QR. Portfel klienta wysyła na tej podstawie invoice_request i otrzymuje konkretną fakturę Lightning, czyli żądanie z danymi danej płatności. Dopiero potem płaci. Klienci mogą więc ponownie korzystać z oferty, otrzymując osobne żądania. Nie oznacza to, że jedna już użyta faktura staje się nową prośbą przy każdym zakupie. Rozdzielenie oferty, zapytania i faktury upraszcza płatności bez mieszania różnych operacji. [4]
Core Lightning pokazuje ten podział wprost. Polecenie fetchinvoice kontaktuje się z wystawcą oferty i pobiera fakturę. Pole changes może wskazać różnice wobec oferty, na przykład w opisie lub kwocie. Poprawna odpowiedź nie wysyła pieniędzy. To jak otrzymanie rachunku w kawiarni: najpierw sprawdzasz, za co i ile zapłacić. Portfel musi przetworzyć otrzymane warunki i osobno rozpocząć płatność. Zakończenia pobierania żądania nie należy mylić z zakończeniem zapłaty. [5]
Dokumentacja pay rozróżnia complete, pending i failed: zakończone, oczekujące i nieudane. Oczekiwanie nie oznacza zapłaty. amount_msat wskazuje kwotę otrzymaną przez odbiorcę, a amount_sent_msat całość wysłaną wraz z opłatami. msat to millisatoshi, tysięczna część satoshi. Klient może więc wydać o opłatę więcej, niż dostaje kawiarnia. Dokumentacja oznacza już pay jako przestarzały interfejs i opisuje przejście na xpay. To wyjaśnienie stanów i kwot, a nie instrukcja instalacji konkretnej wersji; wyniki należy odczytywać zgodnie z używanym programem. [6]
Kiedy kawiarnia oddaje pieniądze, nie przewija pierwotnej płatności wstecz. BOLT 12 opisuje też odwrotny kierunek: sprzedawca podaje kwotę do wysłania, klient dostarcza fakturę, a sprzedawca sprawdza invoice_node_id, identyfikator węzła, któremu ma zapłacić. Następuje nowa płatność do klienta. Nie anuluje to pierwotnego transferu ani nie tworzy automatycznego prawa do zwrotu. Protokół daje sposób jego wykonania; przyczynę i warunki strony muszą uzgodnić oddzielnie. [4]
W sporze warto wiedzieć, co dokładnie potwierdza dowód. BOLT 12 wyjaśnia, że preimage, tajna wartość odpowiadająca skrótowi w żądaniu płatności, może wykazać opłacenie faktury. Po jej ujawnieniu może ją jednak pokazać również ktoś inny; sama nie wskazuje, kto wysłał środki. Klucz w zapytaniu pozwala dowieść, kto poprosił o fakturę, ale nie weryfikuje automatycznie urzędowej tożsamości człowieka. Zapłacona faktura, kontrola nad kluczem i tożsamość klienta są różnymi informacjami. [4]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Andrew Poelstra, Tadge Dryja, Lightning Network. Do tego hasła prowadzą również odsyłacze z Andrew Poelstra, Tadge Dryja.