Rusty Russell

Große Projekte beginnen oft unscheinbar. Der Rückblick von Blockstream vom 9. Juni 2026 erinnert an Russells ersten Commit am 26. Mai 2015: ein kleines Werkzeug zum Erstellen einer Nachricht für die Kanaleröffnung. Ein Commit hält eine Änderung in der Codegeschichte fest. Aus dem frühen Versuch wurde Core Lightning. Russell arbeitete am Programm und an Tests und begleitete andere Entwickler. Der Artikel beschreibt auch seinen Abschied nach elf Jahren. Er erklärt damit nicht alle künftigen Open-Source-Beiträge für beendet; eine frühere Führungsrolle bedeutet ebenso wenig dauerhafte Autorität über das Netzwerk. [1]

Stellen Sie sich ein Café und einen Gast mit unterschiedlichen Programmen vor. Eine Zahlung soll nicht davon abhängen, dass beide denselben Anbieter wählen. Sie brauchen gemeinsame Regeln für Nachrichten und deren Bedeutung. Diese Kommunikation beschreiben die BOLT-Spezifikationen. Russell leitete den gemeinsamen Entwicklungsprozess und förderte Interoperabilität, also die Zusammenarbeit unterschiedlicher Implementierungen. Das öffentliche Repository nimmt Vorschläge und Anmerkungen an. Auch ein wichtiger Mitwirkender kann jedoch nicht allein allen Knoten eine Änderung aufzwingen: Regeln müssen in reale Software und ihre Nutzung eingehen. [1] [2]

Zwei Programme können denselben Absatz unterschiedlich verstehen. Russells lnprototest stellt in Python geschriebene Hilfsmittel bereit, um Szenarien zu formulieren und Reaktionen auf Protokollnachrichten zu prüfen. Die README, das einführende Projektdokument, unterscheidet einen Dummy-Runner von Tests gegen eine echte Implementierung. Eine Simulation hilft bei der Testvorbereitung, aber ihr Erfolg beweist nicht das Verhalten eines tatsächlichen Knotens. Entscheidend ist, was ausgeführt und welche Situationen geprüft wurden. Selbst eine erfolgreiche Testsammlung ist kein vollständiger Audit aller denkbaren Fehler. [3]

Mit BOLT 12 kann das Café ein wiederverwendbares Angebot veröffentlichen, etwa als QR-Code. Die Wallet des Gastes sendet daraus eine invoice_request und erhält eine konkrete Invoice, also eine Zahlungsanforderung mit den Angaben für diese Zahlung. Erst danach wird bezahlt. Das Angebot kann wiederholt genutzt werden, während jeweils einzelne Invoices entstehen. Eine schon verwendete Invoice wird dadurch nicht bei jedem Einkauf zu einer neuen Anforderung. Die Trennung von Angebot, Anfrage und Zahlungsanforderung erleichtert das Bezahlen, ohne verschiedene Einkäufe zu vermischen. [4]

Core Lightning macht diese Trennung sichtbar. Der Befehl fetchinvoice kontaktiert den Anbieter und ruft eine Invoice ab. Das Feld changes kann Abweichungen vom Angebot melden, etwa beim Betrag oder bei der Beschreibung. Eine erfolgreiche Antwort sendet noch kein Geld. Das ähnelt dem Erhalt der Rechnung im Café: Zuerst prüfen Sie, wofür und wie viel Sie bezahlen sollen. Die Wallet muss die erhaltenen Bedingungen auswerten und die Zahlung gesondert starten. Ein erfolgreicher Abruf ist keine abgeschlossene Zahlung. [5]

Die Dokumentation der Schnittstelle pay unterscheidet complete, pending und failed: abgeschlossen, ausstehend und fehlgeschlagen. Ausstehend bedeutet nicht erfolgreich. amount_msat bezeichnet den beim Empfänger angekommenen Betrag, amount_sent_msat den insgesamt versandten Betrag einschließlich Gebühren. msat steht für Millisatoshi, ein Tausendstel eines Satoshi. Der Gast kann also um die Gebühr mehr ausgeben, als das Café erhält. Die Dokumentation kennzeichnet pay inzwischen als veraltet und beschreibt den Übergang zu xpay. Hier geht es um Zustände und Beträge, nicht um eine Installationsanleitung; maßgeblich ist die tatsächlich verwendete Software. [6]

Erstattet das Café Geld, wird die ursprüngliche Zahlung nicht zurückgespult. BOLT 12 beschreibt auch den umgekehrten Ablauf: Das Geschäft nennt den zu sendenden Betrag, der Gast liefert eine Invoice, und das Geschäft prüft invoice_node_id, die Kennung des zu bezahlenden Knotens. Danach folgt eine neue Zahlung an den Gast. Das hebt weder den ursprünglichen Transfer auf noch begründet es automatisch einen Erstattungsanspruch. Das Protokoll stellt das Verfahren bereit; Anlass und Bedingungen müssen die Beteiligten gesondert klären. [4]

Bei Streitfällen zählt, was ein Nachweis tatsächlich belegt. BOLT 12 erklärt, dass ein preimage, der geheime Wert zum Hash in der Zahlungsanforderung, die Bezahlung einer Invoice nachweisen kann. Nach seiner Veröffentlichung kann ihn jedoch auch jemand anderes vorzeigen. Er allein benennt nicht die zahlende Person. Ein Schlüssel in der Anfrage kann belegen, wer die Invoice angefordert hat, bestätigt aber nicht automatisch die bürgerliche Identität. Eine bezahlte Invoice, die Kontrolle über einen Schlüssel und die Identität eines Gastes sind unterschiedliche Informationen. [4]