Diese Woche fasst der Newsletter eine Diskussion über das aktualisierte dynamische Feerate-Anpassungssystem von LND zusammen. Außerdem stellen wir wieder unsere regelmäßigen Rubriken vor, in denen wir kürzlich erfolgte Änderungen an Diensten und Client-Software beschreiben, neue Releases und Release-Kandidaten ankündigen und wichtige Merges in populäre Bitcoin-Infrastruktursoftware zusammenfassen.

News

  • ● Diskussion zum dynamischen Feerate-Anpassungssystem in LND: Matt Morehouse postete im Delving-Bitcoin-Forum eine Beschreibung des kürzlich neu geschriebenen sweeper-Systems in LND, das die Feerates für Onchain-Transaktionen (einschließlich RBF-Fee-Bumps) festlegt. Zu Beginn erläutert er die sicherheitskritischen Aspekte des Feemanagements in einem LN-Knoten und beschreibt das natürliche Bestreben, Gebühren zu vermeiden. Anschließend stellt er zwei generelle Strategien vor, die LND verwendet:

    • Anfragen an externe Feerate-Schätzungen, z.B. an einen lokalen Bitcoin-Core-Knoten oder einen Drittanbieter. Das wird hauptsächlich verwendet, um anfängliche Feerates festzulegen und nicht-zeitkritische Transaktionen zu beschleunigen.

    • Exponentielles Fee-Bumping, sobald sich ein bestimmter Zeitdruck abzeichnet, um zu gewährleisten, dass Probleme mit dem lokalen Mempool oder der Fee-Schätzung nicht zu einer Verzögerung führen. Beispielsweise verwendet Eclair exponentielles Fee-Bumping, wenn die Deadline bei sechs Blöcken liegt.

    Im Anschluss beschreibt Morehouse, wie diese beiden Strategien im neuen Sweeper-System kombiniert werden: „HTLC-Auszahlungen mit ähnlichen Deadlines werden in einer einzigen Batch-Transaktion zusammengefasst. Das Budget für die Batch-Transaktion wird als Summe der Budgets der einzelnen HTLCs berechnet. Auf Basis von Budget und Deadline wird dann eine Gebührenfunktion ermittelt, die steuert, wie viel des Budgets bis zum Erreichen der Deadline verbraucht wird. Standardmäßig wird eine lineare Gebührenfunktion genutzt, die auf einem niedrigen Gebührensatz (bestimmt durch das Minimum-Relay-Gebührenniveau oder einen externen Schätzer) startet und bei nur noch einem Block Restzeit das gesamte Budget für die Gebühr einsetzt.“

    Außerdem beschreibt er, wie die neue Logik effektiv gegen Replacement Cycling-Angriffe schützt und kommt zu dem Schluss: „Mit den Standardparametern von LND muss ein Angreifer mindestens das 20-fache des HTLC-Werts aufwenden, um erfolgreich einen Replacement Cycling-Angriff durchzuführen.“ Er fügt hinzu, dass das neue System auch den Schutz von LND gegen Pinning-Angriffe verbessert.

    Abschließend verlinkt er auf mehrere „LND-spezifische Fehler- und Verwundbarkeitsbehebungen“, die dank der überarbeiteten Logik den Schutz weiter erhöhen. Abubakar Sadiq Ismail antwortete mit Vorschlägen, wie alle LN-Implementierungen (und andere Software) Bitcoin Cores Fee-Schätzung noch effektiver integrieren können. Auch weitere Entwickler kommentierten, fügten der Beschreibung einige Details hinzu.

Änderungen an Diensten und Client-Software

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

Releases und Release-Kandidaten

Neue Veröffentlichungen und Release-Kandidaten populärer Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade oder helfen Sie beim Testen neuer Versionen.

  • ● Bitcoin Core 29.0rc2 ist ein Release-Kandidat für die nächste Hauptversion des am weitesten verbreiteten Full-Nodes im Netzwerk.

Wichtige Änderungen an Code und Dokumentation

Bedeutende jüngste Ä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 #31649 entfernt alle Checkpoint-Logik, die nach der Einführung des Headers-Presync-Verfahrens schon seit einigen Jahren nicht mehr nötig ist (siehe Newsletter #216). Durch den Vergleich der gesamten Proof-of-Work (PoW) mit dem vordefinierten Schwellenwert nMinimumChainWork kann ein Node während des Initial Block Download (IBD) feststellen, ob eine Header-Kette gültig ist. Nur Ketten, deren gesamte PoW diesen Wert übertrifft, werden gespeichert. Dadurch wird effektiv verhindert, dass das Node massenhaft nutzlose Header laden muss. Diese Änderung macht Checkpoints, die oft als zentralisiertes Element galten, überflüssig.

  • ● Bitcoin Core #31283 führt eine neue Methode waitNext() in das BlockTemplate-Interface ein. Sie gibt nur dann ein neues Template zurück, wenn sich die Chain-Spitze ändert oder die Mempool-Gebühren über die MAX_MONEY-Grenze steigen. Zuvor erhielten Miner bei jeder Anfrage ein neues Template, was unnötige Template-Erzeugung verursachte. Diese Änderung bringt das Vorgehen in Einklang mit der Stratum V2-Protokollspezifikation.

  • ● Eclair #3037 erweitert den Befehl listoffers (siehe Newsletter #345), sodass alle relevanten Offer-Daten, einschließlich der Zeitstempel createdAt und disabledAt, ausgegeben werden und nicht nur rohe Type-Length-Value (TLV)-Daten. Zusätzlich behebt das PR einen Fehler, bei dem der Node abstürzte, wenn das gleiche Angebot zweimal registriert werden sollte.

  • ● LND #9546 ergänzt den Befehl lncli constrainmacaroon (siehe Newsletter #201) um das Flag ip_range, das den Zugriff über ein bestimmtes IP-Adressspektrum einschränkt, sofern man ein entsprechendes Macaroon (Authentifizierungstoken) nutzt. Bisher konnten Macaroons nur auf bestimmte IP-Adressen beschränkt oder freigegeben werden.

  • ● LND #9458 führt für bestimmte Peers beschränkte Zugriffsslots ein, konfigurierbar über das Flag --num-restricted-slots, um anfängliche Zugriffsberechtigungen zu steuern. Peers erhalten Stufen für den Zugriff basierend auf ihrer Channel-Historie: Wer einen bestätigten Channel hatte, besitzt „geschützten“ Zugriff; mit einem unbestätigten Channel gibt es vorübergehenden Zugriff; alle anderen bekommen „eingeschränkten“ Zugriff.

  • ● BTCPay Server #6581 fügt RBF-Unterstützung hinzu und ermöglicht damit Fee-Bumping für Transaktionen, die keine Nachkommen haben und deren Inputs aus der Wallet des jeweiligen Stores stammen. Nutzer können nun zwischen CPFP und RBF wählen, um eine Transaktion zuFee-bumpen. Fee-Bumping benötigt NBXplorer Version 2.5.22 oder höher.

  • ● BDK #1839 erweitert die Logik zum Erkennen und Behandeln zurückgezogener (doppelt ausgegebener) Transaktionen durch ein neues Feld TxUpdate::evicted_ats, welches die Timestamps last_evicted in TxGraph aktualisiert. Transaktionen gelten als evicted, wenn der Eintrag in last_evicted über ihrem last_seen-Wert liegt. Der Algorithmus zur Kanonisierung (siehe Newsletter #335) ignoriert solche Transaktionen, solange kein kanonischer Nachfolger aufgrund von Transitivitätsregeln existiert.

  • ● BOLTs #1233 ändert das Node-Verhalten derart, dass ein HTLC niemals upstream beendet wird, wenn dem Node das zugehörige Preimage bekannt ist, was die Begleichung des HTLC sicherstellt. Zuvor empfahl die Spezifikation, ein nicht mehr in einem bestätigten Commitment enthaltenes HTLC upstream zu beenden, selbst wenn man das Preimage kannte. Ein Fehler in älteren LND-Versionen vor 0.18 sorgte bei DoS-Angriffen dafür, dass HTLCs nach einem Neustart abgelehnt wurden, obwohl das Preimage bekannt war, was den Verlust des HTLC-Werts bedeutete (siehe Newsletter #344).