Der Newsletter dieser Woche enthält wie gewohnt unsere regelmäßigen Abschnitte mit Zusammenfassungen zu Updates bei Diensten und Client-Software, der Ankündigung neuer Releases und Release-Kandidaten sowie einer Übersicht wichtiger Änderungen an beliebter Bitcoin-Infrastruktur-Software.

Nachrichten

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

Änderungen an Diensten und Client-Software

In diesem monatlichen Abschnitt stellen wir interessante Neuerungen bei Bitcoin-Wallets und -Diensten vor.

Releases und Release-Kandidaten

Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Releases oder helfen Sie beim Testen von Release-Kandidaten.

  • LND v0.19.2-beta ist das Release einer Wartungsversion dieses beliebten LN-Knotens. Es “enthält wichtige Fehlerbehebungen und Leistungsverbesserungen.”

Wichtige Code- und Dokumentationsänderungen

Wichtige 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 #32604 begrenzt das bedingungslose Schreiben von Logs auf die Festplatte, z.B. für LogPrintf, LogInfo, LogWarning und LogError, um Angriffe zu verhindern, bei denen die Festplatte gefüllt wird. Jeder Ursprungsort erhält ein Kontingent von 1 MB pro Stunde. Alle Logzeilen werden mit einem Stern (*) versehen, wenn ein Ursprungsort unterdrückt wird. Konsolenausgaben, Logs mit explizitem Kategorie-Argument und UpdateTip-Meldungen beim Initial Block Download (IBD) sind von der Begrenzung ausgenommen. Wenn das Kontingent zurückgesetzt wird, gibt Core die Anzahl der verworfenen Bytes aus.

  • Bitcoin Core #32618 entfernt die Option include_watchonly und ihre Varianten sowie das Feld iswatchonly aus allen Wallet-RPCs, da Deskriptor-Wallets keine Mischung aus Watch-only- und ausgebbaren Deskriptoren unterstützen. Zuvor konnten Nutzer eine Watch-only-Adresse oder ein Skript in eine Legacy-Wallet importieren. Legacy-Wallets wurden nun entfernt.

  • Bitcoin Core #31553 fügt dem Cluster-Mempool Projekt eine Behandlung von Block-Reorgs hinzu, indem die Funktion TxGraph::Trim() eingeführt wird. Wenn durch eine Blockchain-Neuordnung (Reorg) bereits bestätigte Transaktionen wieder in den Mempool gelangen und dadurch die erlaubte Anzahl oder das Gewicht eines Transaktions-Clusters überschritten wird, sortiert die Funktion Trim() die Transaktionen nach Gebühr und Abhängigkeiten. Sie entfernt dann alle Transaktionen (und deren Nachfolger), die das Limit überschreiten.

  • Core Lightning #7725 fügt einen leichtgewichtigen JavaScript-Logviewer hinzu, der CLN-Logdateien im Browser lädt und es Nutzern ermöglicht, Nachrichten nach Daemon, Typ, Channel oder Regex zu filtern. Dieses Tool erhöht den Wartungsaufwand des Repos nur minimal und verbessert das Debugging für Entwickler und Knoten-Betreiber.

  • Eclair #2716 implementiert ein lokales Peer-Reputationssystem für HTLC-Endorsements, das die durch jeden eingehenden Peer verdienten Routing-Gebühren im Vergleich zu den Gebühren verfolgt, die basierend auf Liquidität und HTLC-Slots hätten verdient werden sollen. Erfolgreiche Zahlungen führen zu einer perfekten Bewertung, fehlgeschlagene Zahlungen senken sie, und HTLCs, die nach Ablauf der konfigurierten Schwelle noch ausstehen, werden stark bestraft. Beim Weiterleiten gibt der Knoten seine aktuelle Peer-Bewertung im update_add_htlc Endorsement-TLV an (siehe Newsletter #315). Betreiber können den Reputationsverfall (half-life), die Schwelle für festsitzende Zahlungen (max-relay-duration), das Strafgewicht für festsitzende HTLCs (pending-multiplier) anpassen oder das System komplett deaktivieren. Dieser PR sammelt primär Daten zur Verbesserung der Forschung zu Channel Jamming Attacks und implementiert noch keine Strafen.

  • LDK #3628 implementiert die Serverlogik für asynchrone Zahlungen, sodass ein LSP-Knoten BOLT12 statische Rechnungen im Namen eines Empfängers bereitstellen kann, der häufig offline ist. Der LSP-Knoten kann ServeStaticInvoice-Nachrichten vom Empfänger annehmen, die bereitgestellten Rechnungen speichern und auf Zahlungsanfragen des Zahlers reagieren, indem er die gespeicherte Rechnung über Blinded Paths zurückgibt.

  • LDK #3890 ändert die Bewertung von Routen im Pfadfindungsalgorithmus, indem die Gesamtkosten durch das Kanalbetragslimit (Kosten pro nutzbarem Sat) geteilt werden, anstatt nur die Gesamtkosten zu betrachten. Dies bevorzugt Routen mit höherer Kapazität und reduziert übermäßiges MPP Sharding, was zu einer höheren Erfolgsquote bei Zahlungen führt. Obwohl die Änderung kleine Kanäle übermäßig benachteiligt, ist dieser Kompromiss besser als das bisherige starke Sharding.

  • LND #10001 aktiviert das Quieszenz-Protokoll in der Produktion (siehe Newsletter #332) und fügt einen neuen Konfigurationswert --htlcswitch.quiescencetimeout hinzu, der die maximale Dauer angibt, für die ein Channel quieszent sein kann. Der Wert stellt sicher, dass abhängige Protokolle wie dynamische Commitments innerhalb des Zeitlimits abgeschlossen werden. Der Standardwert beträgt 60 Sekunden, das Minimum 30 Sekunden.