400 / 691RUSTY

Rusty Russell

Programista Core Lightning i specyfikacji Lightning

Rusty Russell znacznie przyczynił się do Core Lightning, procesu BOLT i ofert BOLT 12. Jego praca obejmuje implementację, zgodność protokołu i odróżnienie oferty od płatności.

Rusty Russell to programista otwartego oprogramowania związany z początkami Core Lightning i lnprototest. Historyczne przywództwo nie oznacza trwałej władzy nad Lightning ani obecnego zatrudnienia.

Retrospektywa Blockstream z 9 czerwca 2026 roku wspomina pierwszy commit Russella z 26 maja 2015 roku i odejście po jedenastu latach. Nie ogłasza końca wszystkich przyszłych wkładów w otwarty kod. [Blockstream — Rusty Russell retrospective (2026)]

Russell prowadził proces BOLT i wspierał interoperacyjność. Publiczne repozytorium przyjmuje uwagi i propozycje; ważny uczestnik nie może sam narzucić zmian wszystkim węzłom. [Blockstream — Rusty Russell retrospective (2026)] [BOLTs — specification repository]

lnprototest zapewnia narzędzia Python do testów protokołu. README odróżnia symulator od testów prawdziwej implementacji; udana symulacja sama nie dowodzi zgodności realnego węzła. [lnprototest — protocol test framework]

BOLT 12 oddziela opublikowaną ofertę, invoice_request i zwróconą fakturę. Oferta wielokrotnego użytku daje oddzielne faktury; powtarzanie jednej faktury nie tworzy nowych płatności. [BOLT 12 — offers and payment flows]

Core Lightning fetchinvoice pobiera fakturę i zgłasza w changes różnice kwoty lub opisu. Udana odpowiedź sama nie wysyła pieniędzy; otrzymane warunki trzeba sprawdzić. [Core Lightning — fetchinvoice]

pay opisuje complete, pending i failed oraz odróżnia otrzymaną amount_msat od amount_sent_msat z opłatami. Pending nie jest sukcesem, a suma z opłatami nie jest kwotą dla odbiorcy. [Core Lightning — pay]

BOLT 12 opisuje zwrot od sprzedawcy: użytkownik daje fakturę, sprzedawca sprawdza invoice_node_id i płaci. Nie anuluje to pierwotnego przelewu ani nie tworzy automatycznego prawa do zwrotu. [BOLT 12 — offers and payment flows]

BOLT 12 wskazuje, że ujawnione preimage dowodzi opłacenia faktury, ale samo nie identyfikuje płatnika. Klucz żądania może potwierdzić wnioskodawcę faktury, nie weryfikując automatycznie jego tożsamości cywilnej. [BOLT 12 — offers and payment flows]

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.

DOC · 001Blockstream — Rusty Russell retrospective (2026)Dokumentacja ↗DOC · 002BOLTs — specification repositoryDokumentacja ↗DOC · 003lnprototest — protocol test frameworkDokumentacja ↗DOC · 004BOLT 12 — offers and payment flowsDokumentacja ↗DOC · 005Core Lightning — fetchinvoiceDokumentacja ↗DOC · 006Core Lightning — payDokumentacja ↗
Najpierw źródła · To nie jest porada inwestycyjna