Der Newsletter dieser Woche beschreibt eine Sicherheitslücke, die ältere Versionen von LDK betrifft, beleuchtet einen neu bekannt gewordenen Aspekt einer ursprünglich im Jahr 2023 veröffentlichten Sicherheitslücke und fasst die erneute Diskussion über Statistiken zur kompakten Blockrekonstruktion zusammen. Außerdem enthält er unsere regulären Rubriken, in denen populäre Fragen auf der Bitcoin Stack Exchange zusammengefasst, neue Releases und Release-Kandidaten angekündigt sowie aktuelle Änderungen an populärer Bitcoin-Infrastruktursoftware beschrieben werden.

News

  • ● Sicherheitslücke in der LDK-HTLC-Abwicklung: Matt Morehouse hat auf Delving Bitcoin einen Beitrag veröffentlicht, in dem er eine Schwachstelle in LDK aufdeckte – eine Schwachstelle, die er verantwortungsvoll offengelegt hat und die in LDK Version 0.1 behoben wurde.

    Wenn ein Kanal einseitig geschlossen wird und dabei mehrere ausstehende HTLCs vorhanden sind, versucht LDK, möglichst viele HTLCs in einer einzigen Sammeltransaktion abzuwickeln, um Transaktionsgebühren zu sparen. Sollte allerdings die Gegenpartei in der Lage sein, einen der zusammengefassten HTLCs zuerst zu bestätigen, führt dies zu einem Konflikt mit der Sammeltransaktion und macht diese ungültig. LDK erstellt in diesem Fall korrekt eine neue Sammeltransaktion, die den Konflikt behebt. Leider aktualisiert LDK – sofern die Transaktion der Gegenpartei mit mehreren separaten Sammeltransaktionen kollidiert – fälschlicherweise nur die erste, sodass die restlichen Transaktionen nicht bestätigt werden können.

    Die Knoten müssen ihre HTLCs vor Ablauf einer festgelegten Frist abwickeln, da die Gegenpartei sonst in der Lage ist, die Gelder zurückzuholen. Ein Timelock verhindert, dass die Gegenpartei die HTLCs vor ihren individuellen Fristen ausgibt.

    Die meisten älteren Versionen von LDK legten diese HTLCs in eine separate Sammeltransaktion, von der sichergestellt war, dass sie bestätigt wurde, bevor die Gegenpartei eine widersprüchliche Transaktion durchführen konnte – so wurde verhindert, dass Gelder gestohlen werden. Bei HTLCs, die zwar einen Gelddiebstahl nicht zuließen, jedoch von der Gegenpartei umgehend abgewickelt werden konnten, bestand das Risiko, dass diese Gelder blockiert werden. Morehouse schreibt, dass dieses Problem behoben werden kann, indem man „auf LDK Version 0.1 aktualisiert und die Abfolge der Commitment- und HTLC-Transaktionen, die zur Blockade geführt haben, erneut abspielt.”

    Der Release-Kandidat LDK 0.1-beta änderte jedoch seine Logik (siehe Newsletter #335) und begann damit, alle Arten von HTLCs zusammenzufassen, wodurch ein Angreifer in die Lage versetzt würde, einen Konflikt mit einem HTLC, der einem Timelock unterliegt, zu erzeugen. Bleibt die Auflösung dieses HTLCs auch nach Ablauf des Timelocks blockiert, wäre ein Diebstahl möglich. Ein Upgrade auf die Release-Version von LDK 0.1 behebt auch diese Art der Schwachstelle.

    Morehouses Beitrag liefert weitere Details und diskutiert mögliche Ansätze, um zukünftige Schwachstellen, die aus derselben Grundursache resultieren, zu verhindern.

  • ● Angriffe durch Replacement Cycling mit Ausnutzung von Minern: Antoine Riard hat auf der Bitcoin-Dev-Mailingliste einen Beitrag veröffentlicht, um eine weitere Schwachstelle offenzulegen, die mit dem Replacement Cycling Angriff möglich ist – einem Angriff, den er ursprünglich 2023 öffentlich bekannt machte (siehe Newsletter #274).

    Kurz zusammengefasst:

    1. Bob sendet eine Transaktion, in der er an Mallory (und möglicherweise an weitere Empfänger) zahlt.

    2. Mallory pinnt Bobs Transaktion.

    3. Bob bemerkt nicht, dass seine Transaktion gepinnt wurde, und erhöht die Gebühren (entweder mittels RBF oder CPFP).

    4. Da Bobs ursprüngliche Transaktion gepinnt wurde, wird seine Gebührenanhebung nicht weiterverbreitet – dennoch gelangt sie irgendwie zu Mallory. Die Schritte 3 und 4 können mehrfach wiederholt werden, um Bobs Gebühren erheblich in die Höhe zu treiben.

    5. Mallory baut Bobs höchste Gebührenanhebung in einen Block ein – diesen versucht sonst kein anderer Miner zu verarbeiten, da er aufgrund der fehlenden Propagation nicht im Netzwerk ankommt. Dadurch kann Mallory mehr Gebühren verdienen als andere Miner.

    6. Mallory kann nun das Replacement Cycling einsetzen, um ihren Transaktions-Pin auf eine andere Transaktion zu übertragen und den Angriff zu wiederholen (möglicherweise sogar mit einem anderen Opfer), ohne zusätzliche Mittel aufzubringen. Somit erweist sich der Angriff als wirtschaftlich effizient.

    Wir beurteilen diese Schwachstelle nicht als ein signifikantes Risiko. Die Ausnutzung setzt spezielle, möglicherweise seltene Umstände voraus und kann dazu führen, dass ein Angreifer Geld verliert, wenn er die Netzbedingungen falsch einschätzt. Sollte ein Angreifer die Schwachstelle regelmäßig ausnutzen, gehen wir davon aus, dass sein Verhalten von Community-Mitgliedern, die Block-Monitoring-Tools entwickeln und einsetzen, bemerkt wird.

  • ● Aktualisierte Statistiken zur Kompaktblock-Rekonstruktion: Auf einen vorherigen Thread (siehe Newsletter #315) folgend, hat Entwickler 0xB10C in einem Beitrag an Delving Bitcoin aktualisierte Statistiken darüber veröffentlicht, wie häufig seine Bitcoin Core-Knoten zusätzliche Transaktionen anfordern müssen, um die Kompaktblock-Rekonstruktion durchzuführen.

    Wenn ein Knoten einen Kompaktblock empfängt, muss er alle Transaktionen anfordern, die in diesem Block enthalten sind, sich aber nicht bereits in seinem Mempool (oder in seinem Extrapool, einem speziellen Reservenpool zur Unterstützung der Kompaktblock-Rekonstruktion) befinden. Diese zusätzliche Anforderung verlangsamt die Blockpropagation erheblich und trägt zur Zentralisierung der Miner bei.

    0xB10C stellte fest, dass die Häufigkeit der Anfragen signifikant zunimmt, je größer der Mempool wird. Mehrere Entwickler diskutierten mögliche Ursachen, wobei erste Daten darauf hindeuteten, dass es sich bei den fehlenden Transaktionen um Orphan-Transaktionen handelt – Kindtransaktionen von unbekannten Eltern, die Bitcoin Core nur kurzfristig speichert, falls deren Eltern in einem kurzen Zeitfenster eintreffen. Eine verbesserte Verfolgung und das Anfordern der Eltern von Orphan-Transaktionen, die kürzlich in Bitcoin Core integriert wurden (siehe Newsletter #338), könnte diese Situation verbessern.

    Die Entwickler diskutierten auch andere mögliche Lösungen. Knoten können Orphan-Transaktionen nicht lange speichern, da ein Angreifer diese kostenlos erstellen kann – es könnte jedoch möglich sein, eine größere Anzahl von Orphan-Transaktionen und anderen verworfenen Transaktionen länger im Extrapool vorzuhalten. Die Diskussion war zum Zeitpunkt der Erstellung dieses Beitrags noch nicht abschließend geklärt.

Ausgewählte Q&A vom Bitcoin Stack Exchange

Bitcoin Stack Exchange ist einer der ersten Orte, an denen die Optech-Mitwirkenden nach Antworten auf ihre Fragen suchen – oder wenn wir ein paar freie Momente haben, um neugierige oder verwirrte Nutzer zu unterstützen. In diesem monatlichen Feature heben wir einige der bestbewerteten Fragen und Antworten hervor, die seit unserem letzten Update gepostet wurden.

Releases und Release-Kandidaten

Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie, auf die neuen Releases zu aktualisieren oder bei der Erprobung der Release-Kandidaten zu helfen.

  • ● LDK v0.1.1 ist ein Sicherheits-Release dieser beliebten Bibliothek zum Erstellen von LN-fähigen Anwendungen. Ein Angreifer, der bereit ist, mindestens 1 % der Kanalgelder zu opfern, könnte das Opfer dazu verleiten, andere, nicht damit zusammenhängende Kanäle zu schließen, was dazu führen könnte, dass das Opfer unnötig Transaktionsgebühren zahlt. Matt Morehouse, der die Schwachstelle entdeckt hat, hat darüber bei Delving Bitcoin berichtet; Optech wird in der nächsten Ausgabe des Newsletters eine detailliertere Zusammenfassung liefern. Das Release beinhaltet außerdem API-Updates und Fehlerbehebungen.

Wesentliche Änderungen im Code und in der Dokumentation

Wichtige aktuelle Ä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 #31376 erweitert eine Prüfung, die verhindert, dass Miner Blockvorlagen erstellen, welche den Timewarp-Fehler ausnutzen – und zwar für alle Netzwerke, nicht nur für testnet4. Diese Änderung dient als Vorbereitung für einen möglichen zukünftigen Soft Fork, der den Timewarp-Fehler dauerhaft beheben würde.

  • ● Bitcoin Core #31583 aktualisiert die RPC-Befehle getmininginfo, getblock, getblockheader, getblockchaininfo und getchainstates, sodass nun ein nBits-Feld (die kompakte Darstellung des Block-Schwierigkeitsziels) sowie ein target-Feld zurückgegeben werden. Zusätzlich fügt getmininginfo ein next-Objekt hinzu, das die Höhe, nBits, den Schwierigkeitsgrad und das Ziel für den nächsten Block spezifiziert. Um das Ziel abzuleiten und zu erhalten, führt dieser PR die Hilfsfunktionen DeriveTarget() und GetTarget() ein. Diese Änderungen sind nützlich für die Implementierung von Stratum V2.

  • ● Bitcoin Core #31590 überarbeitet die Methode GetPrivKey(), sodass beim Abrufen privater Schlüssel für einen x-only-Pubkey in einem Descriptor beide möglichen Werte des Paritätsbits überprüft werden. Zuvor konnte, wenn der gespeicherte Pubkey nicht das korrekte Paritätsbit aufwies, der private Schlüssel nicht abgerufen werden, und Transaktionen konnten nicht signiert werden.

  • ● Eclair #2982 führt die Konfigurationseinstellung lock-utxos-during-funding ein, die es Verkäufern von liquidity advertisements ermöglicht, einen bestimmten Liquiditätsgriefing-Angriff abzumildern, der ehrlichen Nutzern verhindern könnte, ihre UTXOs über längere Zeiträume zu verwenden. Die Standardeinstellung ist auf true gesetzt, was bedeutet, dass UTXOs während des Funding-Prozesses gesperrt werden und somit anfällig für Missbrauch sind. Wird der Wert auf false gesetzt, wird die UTXO-Sperrung deaktiviert und der Angriff kann vollständig verhindert werden – dies könnte jedoch negative Auswirkungen auf ehrliche Peers haben. Dieses PR fügt außerdem einen konfigurierbaren Timeout-Mechanismus hinzu, der eingehende Kanäle automatisch abbricht, wenn ein Peer nicht reagiert.

  • ● BDK #1614 fügt Unterstützung für die Verwendung von kompakten Blockfiltern hinzu, wie sie in BIP158 spezifiziert sind, um bestätigte Transaktionen herunterzuladen. Dies wird erreicht, indem dem bdk_bitcoind_rpc Crate ein BIP158-Modul hinzugefügt wird, zusammen mit einem neuen FilterIter-Typ, der verwendet werden kann, um Blöcke abzurufen, die Transaktionen enthalten, welche für eine Liste von Script-Pubkeys relevant sind.

  • ● BOLTs #1110 führt die Spezifikation für das Peer Storage-Protokoll zusammen, welches es Knoten ermöglicht, verschlüsselte Blobs von bis zu 64kB für anfragende Peers zu speichern und für diesen Dienst Gebühren zu erheben. Diese Funktion wurde bereits in Core Lightning (siehe Newsletter #238) und Eclair (siehe Newsletter #335) implementiert.