Der Newsletter dieser Woche enthält unsere regulären Abschnitte mit Beschreibungen aktueller Änderungen an Diensten und Client-Software, Ankündigungen neuer Releases und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an beliebter Bitcoin-Infrastruktur-Software. Außerdem gibt es eine Korrektur zu einigen Details aus unserem Bericht der letzten Woche über SwiftSync.

Nachrichten

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

Änderungen an Diensten und Client-Software

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

  • ● Bitcoin Knots Version 28.1.knots20250305 veröffentlicht: Dieser Release von Bitcoin Knots unterstützt das Signieren von Nachrichten für Segwit- oder Taproot-Adressen sowie die Verifizierung von BIP137, BIP322 und Electrum-signierten Nachrichten, neben weiteren Änderungen.

  • ● PSBTv2 Explorer angekündigt: Der Bitcoin PSBTv2 Explorer ermöglicht die Inspektion von PSBTs, die im Version-2-Datenformat kodiert sind.

  • ● LNbits v1.0.0 veröffentlicht: Die LNbits Software bietet Buchhaltung und zusätzliche Funktionen auf Basis verschiedener Lightning Network Wallets.

  • ● The Mempool Open Source Project® v3.2.0 veröffentlicht: Der v3.2.0 Release fügt Unterstützung für v3-Transaktionen, Anchor Outputs, das Broadcasting von 1P1C-Paketen, die Visualisierung von Stratum-Miningpool-Jobs und weitere Funktionen hinzu.

  • ● Coinbase MPC-Bibliothek veröffentlicht: Das Coinbase MPC Projekt ist eine C++-Bibliothek zur Sicherung von Schlüsseln für Multi-Party-Computing (MPC)-Schemata, einschließlich einer eigenen secp256k1-Implementierung.

  • ● Lightning Network Liquiditäts-Tool veröffentlicht: Hydrus nutzt den Zustand des LN-Netzwerks, einschließlich vergangener Performance, um Lightning-Kanäle für LND automatisch zu öffnen und zu schließen. Es unterstützt auch Batching.

  • ● Versioned Storage Service angekündigt: Das Versioned Storage Service (VSS) Framework ist eine Open-Source-Cloudspeicherlösung für Lightning- und Bitcoin-Wallet-State-Daten mit Fokus auf non-custodial Wallets.

  • ● Fuzz-Testing-Tool für Bitcoin-Knoten: Fuzzamoto ist ein Framework, um mit Fuzz-Testing Fehler in verschiedenen Bitcoin-Protokollimplementierungen über externe Schnittstellen wie P2P und RPC zu finden.

  • ● Bitcoin Control Board Komponenten Open Source: Braiins kündigte die Open-Source-Verfügbarkeit einiger Hardware- und Software-Komponenten ihres BCB100-Mining-Control-Boards an.

Veröffentlichungen und Release-Kandidaten

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

  • ● Bitcoin Core 29.0 ist die neueste Hauptversion des vorherrschenden Full Nodes im Netzwerk. Die Release Notes beschreiben mehrere bedeutende Verbesserungen: Ersatz der standardmäßig deaktivierten UPnP-Funktion (die in der Vergangenheit für einige Sicherheitslücken verantwortlich war) durch eine NAT-PMP-Option (ebenfalls standardmäßig deaktiviert), verbessertes Abrufen von Elternteilen verwaister Transaktionen zur Erhöhung der Zuverlässigkeit des aktuellen Package Relay in Bitcoin Core, etwas mehr Platz in Standard-Blockvorlagen (was potenziell die Miner-Einnahmen verbessert), Verbesserungen zur Vermeidung versehentlicher Timewarps für Miner, die andernfalls Einnahmeverluste riskieren könnten, falls Timewarps in einem zukünftigen Soft Fork verboten werden, und eine Migration des Build-Systems von autotools zu cmake.

  • ● LND 0.19.0-beta.rc2 ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die wahrscheinlich getestet werden sollte, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen.

Wichtige 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.

  • ● LDK #3593 ermöglicht es Nutzern, einen BOLT12 Zahlungsnachweis zu liefern, indem die BOLT12-Rechnung im PaymentSent-Event nach Abschluss einer Zahlung enthalten ist. Dies wird durch das Hinzufügen des Feldes bolt12 zum Enum PendingOutboundPayment::Retryable erreicht, das dann an das PaymentSent-Event angehängt werden kann.

  • ● BOLTs #1242 macht das Payment Secret für BOLT11-Rechnungszahlungen verpflichtend, indem von Lesern (Zahlern) verlangt wird, eine Zahlung zu verweigern, wenn das Feld s (Payment Secret) fehlt. Zuvor war es nur für Schreiber (Empfänger) verpflichtend, und Leser konnten s-Felder mit falscher Länge ignorieren (siehe Newsletter #163). Dieser PR aktualisiert auch das Payment Secret Feature auf den Status ASSUMED in BOLT9.

Korrektur

Der Bericht der letzten Woche über SwiftSync enthielt mehrere Fehler und verwirrende Aussagen.

  • ● Kein kryptografischer Akkumulator verwendet: Wir beschrieben SwiftSync als Verwendung eines kryptografischen Akkumulators, was nicht korrekt ist. Ein kryptografischer Akkumulator würde es ermöglichen zu testen, ob ein bestimmter Transaktionsoutput (TXO) Teil einer Menge ist. SwiftSync benötigt das nicht. Stattdessen wird ein Wert, der einen TXO repräsentiert, beim Erstellen zum Aggregat addiert und beim Ausgeben (Verbrauchen) subtrahiert. Nach Durchführung dieses Vorgangs für alle TXOs, die vor dem SwiftSync-Endblock ausgegeben werden sollten, prüft der Knoten, ob das Aggregat null ist – was bedeutet, dass alle erstellten TXOs später ausgegeben wurden.

  • ● Parallele Blockvalidierung erfordert kein assumevalid: Wir beschrieben einen Weg, wie parallele Validierung mit SwiftSync funktionieren könnte, bei dem Skripte bis zum Endblock von SwiftSync nicht validiert werden – ähnlich wie Bitcoin Core heute während des Initial Syncs mit assumevalid. Allerdings könnten frühere Skripte mit SwiftSync validiert werden, was wahrscheinlich Änderungen am Bitcoin-P2P-Protokoll erfordern würde, um optional zusätzliche Daten mit Blöcken zu übertragen. Bitcoin Core Knoten speichern diese Daten bereits für jeden Block, den sie ebenfalls speichern, daher glauben wir nicht, dass das Hinzufügen einer P2P-Nachrichtenerweiterung schwierig wäre, falls erwartet wird, dass viele Leute SwiftSync mit deaktiviertem assumevalid nutzen wollen.

  • ● Parallele Blockvalidierung aus anderen Gründen als bei Utreexo: Wir schrieben, dass SwiftSync Blöcke aus ähnlichen Gründen wie Utreexo parallel validieren kann, aber beide gehen unterschiedlich vor. Utreexo validiert einen Block (oder eine Serie von Blöcken zur Effizienzsteigerung), indem es mit einem Commitment zum UTXO-Set beginnt, alle Änderungen am UTXO-Set durchführt und ein Commitment zum neuen UTXO-Set erzeugt. Dadurch kann die Validierungsarbeit nach CPU-Threads aufgeteilt werden; z.B. validiert ein Thread die ersten tausend Blöcke und ein anderer Thread die zweiten tausend Blöcke. Am Ende der Validierung prüft der Knoten, ob das Commitment am Ende der ersten tausend Blöcke mit dem Commitment übereinstimmt, mit dem er für die zweiten tausend Blöcke gestartet ist.

    SwiftSync verwendet einen Aggregatzustand, der Subtraktion vor Addition erlaubt. Angenommen, ein TXO wird in Block 1 erstellt und in Block 2 ausgegeben. Wenn wir Block 2 zuerst verarbeiten, subtrahieren wir die Darstellung des TXO vom Aggregat. Wenn wir später Block 1 verarbeiten, addieren wir die Darstellung des TXO zum Aggregat. Der Nettoeffekt ist null, was am Ende der SwiftSync-Validierung überprüft wird.

Wir entschuldigen uns bei unseren Lesern für unsere Fehler und danken Ruben Somsen für den Hinweis darauf.