Heute begrüssen wir die neueste Core Lightning-Version, v23.11, mit dem Codenamen Bitcoin Orangepaper (mit freundlicher Genehmigung von Shahana Farooqui). Nach der grossen Veröffentlichung v23.08 ist dieses Update etwas kleiner und bietet hauptsächlich Verbesserungen und Followups. Dennoch enthält es einige bemerkenswerte Funktionen, die wir Ihnen gerne mitteilen möchten.
Dual Funding hat Kompatibilitätsniveau erreicht: Nach einem langen Weg hat der Dual Funding Prozess endlich Implementierungskompatibilität erreicht.
RPC-Befehlsaktualisierungen: Diese Version enthält einige tolle Ergänzungen und Aktualisierungen für die Core Lightning API, darunter einen viel leistungsfähigeren check Befehl und einen brandneuen restore Befehl.
Core Lightning für Entwickler: Die verschiedenen Schnittstellen von Core Lightning wachsen weiter und Runes haben ein interessantes neues Feld bekommen. Wir haben auch einige neue Optionen!
Dual Funding in greifbarer Nähe!
Den Dual Funding Vorschlag gibt es schon seit mehreren Jahren. Da Core Lightning der erste Lightning Node war, der offiziell Dual Funding unterstützte, ist es keine Überraschung, dass wir Fans sind, also lasst uns noch einmal darüber reden!
Bei einem herkömmlichen Kanal Funding Prozess wird die Funding Transaktion ausschliesslich von der Partei finanziert, die einen neuen Kanal initiiert. Dies bedeutet, dass trotz der kooperativen Gestaltung nur dieser Partner Inputs und Outputs in die Finanzierungstransaktion einbringen kann.
Mithilfe des interaktiven Dual-Funding-Protokolls können beide Parteien am Finanzierungsprozess teilnehmen, indem sie Inputs und Outputs zur Finanzierungstransaktion beitragen (interactive-tx sub-protocol). Dies wird erreicht, indem während einer Verhandlungsphase Updates zu den gewünschten In- und Outputs ausgetauscht werden. Sobald sich beide Parteien über ihre Ergänzungen zur Finanzierungstransaktion geeinigt haben, tauschen sie die erforderlichen Signaturen aus und können mit dem Abschluss der Finanzierungstransaktion und der anfänglichen Commitment Transaktion fortfahren.
Dieser Prozess ermöglicht die Erstellung von Kanälen mit Salden ungleich Null an beiden Enden. Ein Vorteil davon ist die Möglichkeit, Kanäle für sofortige Zahlungen in beide Richtungen ohne vorherige Saldenverschiebung einzurichten.
Kommen wir nun zu den Neuigkeiten:
Ein grundlegender Aspekt des BOLT-Spezifikationsprozesses ist die Forderung nach zwei separaten und kompatiblen Implementierungen eines Vorschlags, bevor er in einen BOLT aufgenommen werden kann.
Die jüngsten Beiträge von Lisa Neigut zur Implementierung von Dual Funding in Core Lightning ermöglichen die Fortsetzung des Finanzierungsprozesses im Falle eines vorübergehenden Verbindungsverlusts. Dies war der letzte Schritt für Core Lightning und Eclair, um gegenseitige Kompatibilität zu erreichen.
Updates für RPC-Befehle
Diese Core Lightning-Version bringt einige bemerkenswerte Updates und Ergänzungen zur API.
Aufbauend auf den Grundlagen, die durch die Option --recover der vorherigen Version gelegt wurden, erweitert diese Version sie zu einem RPC-Befehl recover, auf die über Plugins und verschiedene Schnittstellen zugegriffen werden kann. Hinter den Kulissen bewirkt der Befehl, dass der Knoten mit aktivierter Option --recover neu gestartet wird. Diese Funktion ist besonders für Frontend-Anwendungen von Vorteil.
Zusammen mit der Einführung von recover erhielt check ein bedeutendes Upgrade und wurde noch leistungsfähiger. Zusätzlich zur Validierung des Befehlsformats und der Parameter führt check eine gründliche Analyse durch, ohne den Systemstatus zu ändern.
Die Verbindung beider Befehle ermöglicht es, zu überprüfen, ob eine Wiederherstellung durchgeführt werden kann, ohne dies tatsächlich zu tun, was hilfreich sein kann, um robuste Benutzeroberflächen zu erstellen.
Ein weiteres Beispiel für die verbesserten Fähigkeiten des check-Befehls ist der delinvoice Befehl. delinvoice nutzt die Parameter label und status, um eine Invoice aus der Datenbank zu entfernen. Zuvor validierte check den Befehl formal, indem er das Vorhandensein beider erforderlicher Parameter sicherstellte. Mit diesem Update führt check eine tiefergehende Analyse durch, prüft das Vorhandensein einer Invoice mit dem angegebenen label und bestätigt, dass der status übereinstimmt.
Beispiel:
$ lightning-cli check delinvoice "l1" "paid"
{
"code": 906,
"message": "Invoice status is unpaid not paid",
"data": {
"current_status": "unpaid",
"expected_status": "paid"
}
}Das decode Kommando wurde ebenfalls aktualisiert. decode kann jetzt einen Notfall Recover String verarbeiten, der es einem Benutzer ermöglicht, die Integrität und Gültigkeit der Datei „emergency.recover“ zu überprüfen. Der Notfall Recover String kann mit dem neuen Befehl getemergencyrecover des hsmtool abgerufen werden.
Diese Updates bieten ein robustes Framework, das es Benutzern erleichtert, ihren Core Lightning Node sicher zu betreiben.
Apropos sicherer Betrieb eines Core Lightning Node: Runes haben eine neue Einschränkung erhalten, die mehr Flexibilität und eine feinkörnigere Zugriffsverwaltung ermöglicht. Die per Einschränkung ermöglicht ein allgemeines Rate Limiting und berücksichtigt eine Reihe von Zeiteinheiten wie Sekunden, Millisekunden usw. Um dies zu ermöglichen, verfolgt Core Lightning jetzt einen last_used Zeitstempel pro Rune, der auch dem Befehl showrunes hinzugefügt wird.
Diese Version aktualisiert ausserdem alle Zeitfelder auf Nanosekunden. Dies betrifft die listforwards Felder received_time, resolved_time sowie die Felder listpays und listsendpays created_at.
Zusätzlich zu recover, was Core Lightning für Front-End-Anwendungen zugänglicher macht, wurden die Warte- und Paginierungs-APIs erweitert. wait unterstützt jetzt zwei weitere Subsysteme listforwards und listsendpay. Diese Updates ermöglichen das Warten auf jede Statusänderung bei weitergeleiteten HTLCs und Zahlungen und fügen Paginierung zu listforwards und listsendpay hinzu. Diese Ergänzungen sind besonders für Frontend-Entwickler nützlich, um das Benutzererlebnis zu verbessern. Um diese einem breiteren Publikum zugänglich zu machen, wurde das Wartesystem auf den Rust- und gRPC-Schnittstellen aktiviert.
Ein weiterer netter Befehl, der dem Dienstprogramm-Arsenal von Core Lightning hinzugefügt wurde, ist datastoreusage. Dieser Befehl bietet einen klaren Überblick über den von Datastore Einträgen belegten Datenbankspeicherplatz, ohne dass die Daten manuell quantifiziert werden müssen.
Diese Reihe von Befehlsaktualisierungen erweitert nicht nur die Funktionalität von Core Lightning, sondern verbessert auch das Benutzer- und Entwicklerlebnis und unterstreicht damit die kontinuierliche Weiterentwicklung der Plattform.
Andere bemerkenswerte Updates
Mit dieser Version hat Core Lightning die alte Methode zum Aktivieren der Entwicklerfunktionalität auf einem Node begraben. Bisher war es notwendig, Core Lightning von Grund auf zu kompilieren. Um die Entwicklerfunktionalität zu aktivieren, muss man nun lediglich lightningd mit der Laufzeitvariablen --developer starten. Dies ist eine enorme Vereinfachung für Entwickler.
Core Lightning ermöglicht jetzt standardmässig grosse Kanäle. Während der frühen Entwicklung des Lightning Networks beschlossen die Entwickler, die maximale Kanalgrösse vorübergehend auf unter 0,16777216 BTC zu begrenzen. Diese Entscheidung wurde getroffen, um den Betrag zu begrenzen, den ein Benutzer durch Softwarefehler verlieren könnte. Heutzutage können Kanäle diese Grenze überschreiten, doch dafür muss ein Node seine Unterstützung und Bereitschaft dazu signalisieren. Diese Version legt die Indikatoren standardmässig fest und ermöglicht „Wumbologie für alle“. Benutzer können nach wie vor Wumbo Kanäle durch Setzen der --large-channels=false Option deaktivieren.
Letztendlich bietet diese Version auch die Möglichkeit, Invoices zu erstellen, die eine Fallback P2TR Adresse enthalten. So kann eine Rechnung beispielsweise auch dann on-chain bezahlt werden, wenn zum Zeitpunkt der Zahlung nicht genügend eingehende Liquidität vorhanden ist. Core Lightning verfolgt jetzt Zahlungen an Fallback Adressen und schliesst die dazugehörigen Invoices. Die Fallback Adressen können durch Setzen der Konfigurationsoption invoices-onchain-fallback aktiviert werden.
Treten Sie der CLN Community bei
Wir möchten den Mitwirkenden (insgesamt 29 für die Version 23.11), die uns stets dabei helfen, CLN mit jedem Update zu verbessern, unseren Dank aussprechen. Wir sind dankbar für Ihre Unterstützung; Ihr Engagement und Feedback haben die neue Release ermöglicht.
Wie immer sind Sie eingeladen, uns mitzuteilen, was Ihnen gefällt, oder Verbesserungsvorschläge in einem Thread auf Build On L2 zu schreiben. Dort haben wir spezielle Entwickler- und Node Runner-Seiten, um ausführliche Diskussionen zu ermöglichen. Die Anmeldung ist kostenlos und Nyms sind herzlich willkommen!
Sie können uns auch über unsere üblichen Social Media Kanäle erreichen: Twitter, Telegram oder Discord.
Eine letzte Überraschung: Behalten Sie den Blockstream YouTube-Kanal im Auge. Wir haben eine Reihe spezieller Podcast-Episoden mit Rusty Russell, Christian Decker und anderen CLN-Mitwirkenden, in denen wir detailliert auf die neue Release eingehen.
Nochmals vielen Dank an die Community und alle, die Core Lightning weiterhin grossartig machen!