Der Newsletter dieser Woche enthält unsere regulären Abschnitte mit Beschreibungen von Änderungen an Diensten und Client-Software, Ankündigungen neuer Veröffentlichungen und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an beliebter Bitcoin-Infrastruktursoftware.

Nachrichten

In dieser Woche wurden keine bedeutenden Nachrichten in unseren Quellen gefunden.

Änderungen an Diensten und Client-Software

In dieser monatlichen Rubrik stellen wir interessante Aktualisierungen von Bitcoin-Wallets und -Diensten vor.

Veröffentlichungen und Release-Kandidaten

Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Veröffentlichungen oder helfen Sie bei der Überprüfung von Release-Kandidaten.

  • ● LND 0.19.0-beta ist die neueste Hauptversion dieses beliebten LN-Knotens. Sie enthält viele Verbesserungen und Fehlerbehebungen, einschließlich neuem RBF-basierten Fee-Bumping für kooperative Schließungen.

  • ● Core Lightning 25.05rc1 ist ein Release-Kandidat für die nächste Hauptversion dieser beliebten LN-Knoten-Implementierung.

Erwähnenswerte Code- und Dokumentationsänderungen

Nennenswerte kürzliche Änderungen in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition und BINANAs.

  • ● Bitcoin Core #32423 entfernt den Hinweis, dass rpcuser/rpcpassword als veraltet markiert ist, und ersetzt ihn durch eine Sicherheitswarnung bezüglich der Speicherung von Klartext-Anmeldedaten in der Konfigurationsdatei. Diese Option wurde ursprünglich als veraltet markiert, als rpcauth in Bitcoin Core #7044 eingeführt wurde, welches mehrere RPC-Benutzer unterstützt und seinen Cookie hasht. Der PR fügt außerdem ein zufälliges 16-Byte-Salt zu Anmeldedaten aus beiden Methoden hinzu und hasht diese, bevor sie im Speicher gespeichert werden.

  • ● Bitcoin Core #31444 erweitert die TxGraph-Klasse (siehe Newsletter #348) um drei neue Hilfsfunktionen: GetMainStagingDiagrams() gibt die Abweichungen von Clustern zwischen den Haupt- und Staging-Feerate-Diagrammen zurück, GetBlockBuilder() iteriert durch Graph-Chunks (nach Feerate sortierte Teilcluster-Gruppierungen) von höchster bis niedrigster Feerate für optimierte Blockerstellung, und GetWorstMainChunk() identifiziert den Chunk mit der niedrigsten Feerate für Entscheidungen zur Räumung. Dieser PR ist einer der letzten Bausteine der vollständigen ersten Implementierung des Cluster-Mempool-Projekts.

  • ● Core Lightning #8140 aktiviert standardmäßig die Peer-Speicherung von Kanal-Sicherungen (siehe Newsletter #238) und macht sie für große Knoten praktikabel, indem die Speicherung auf Peers mit aktuellen oder früheren Kanälen begrenzt wird, Daten im Speicher zwischengespeichert werden anstatt wiederholte listdatastore/listpeerchannels-Aufrufe zu tätigen, gleichzeitige Uploads auf zwei Peers begrenzt werden, Daten größer als 65 kB übersprungen werden und beim Senden eine zufällige Auswahl der Peers getroffen wird.

  • ● Core Lightning #8136 aktualisiert den Austausch von Ankündigungssignaturen so, dass er stattfindet, wenn der Kanal bereit ist, anstatt nach sechs Blöcken, um mit der kürzlichen BOLTs #1215 Spezifikationsaktualisierung übereinzustimmen. Es ist immer noch erforderlich, sechs Blöcke zu warten, um den Kanal anzukündigen.

  • ● Core Lightning #8266 fügt einen update-Befehl zum Reckless-Plugin-Manager hinzu (siehe Newsletter #226), der ein bestimmtes Plugin oder alle installierten Plugins aktualisiert, wenn keines angegeben ist, außer solche, die von einem festen Git-Tag oder -Commit installiert wurden. Dieser PR erweitert auch den install-Befehl, um einen Quellpfad oder eine URL zusätzlich zu einem Plugin-Namen zu akzeptieren.

  • ● Core Lightning #8021 finalisiert die Splicing-Interoperabilität mit Eclair (siehe Newsletter #331), indem die Rotation der Remote-Funding-Keys korrigiert wird, splice_locked bei der Kanal-Wiederherstellung erneut gesendet wird, um Fälle abzudecken, in denen es ursprünglich verpasst wurde (siehe Newsletter #345), die Anforderung gelockert wird, dass commitment-signed-Nachrichten in einer bestimmten Reihenfolge ankommen müssen, das Empfangen und Initiieren von Splice-RBF-Transaktionen ermöglicht wird, ausgehende PSBTs bei Bedarf automatisch in Version 2 konvertiert werden und andere Refactoring-Änderungen vorgenommen werden.

  • ● Core Lightning #8226 implementiert BIP137 durch Hinzufügen eines neuen signmessagewithkey-RPC-Befehls, der es Benutzern ermöglicht, Nachrichten mit einem beliebigen Schlüssel aus der Wallet zu signieren, indem eine Bitcoin-Adresse angegeben wird. Früher erforderte das Signieren einer Nachricht mit einem Core Lightning-Schlüssel, den xpriv und den Schlüsselindex zu finden, den privaten Schlüssel mit einer externen Bibliothek abzuleiten und dann die Nachricht mit Bitcoin Core zu signieren.

  • ● LND #9801 fügt eine neue Option --no-disconnect-on-pong-failure hinzu, die steuert, ob ein Peer getrennt wird, wenn eine Pong-Antwort verspätet oder nicht übereinstimmend ist. Diese Option ist standardmäßig auf false gesetzt, wodurch das aktuelle Verhalten von LND beibehalten wird, sich bei einem Pong-Nachrichtenfehler von einem Peer zu trennen (siehe Newsletter #275); andernfalls würde LND das Ereignis nur protokollieren. Der PR refaktoriert den Ping-Watchdog, um seine Schleife fortzusetzen, wenn die Trennung unterdrückt wird.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on May 27. The discussion is also recorded and will be available from our podcasts page.