Der Newsletter dieser Woche fasst eine Diskussion über die möglichen Auswirkungen von zuordenbaren Fehlern auf die Privatsphäre im Lightning Netzwerk (LN) zusammen. Ebenfalls enthalten sind unsere regulären Abschnitte mit ausgewählten Fragen und Antworten von Bitcoin Stack Exchange, Ankündigungen neuer Releases und Release-Kandidaten sowie Beschreibungen aktueller Änderungen an beliebter Bitcoin-Infrastruktur-Software.

Nachrichten

• ● Beeinträchtigen zuordenbare Fehler die Privatsphäre im Lightning Netzwerk? Carla Kirk-Cohen veröffentlichte auf Delving Bitcoin eine Analyse der möglichen Folgen für die Privatsphäre von LN-Zahlenden und -Empfangenden, falls das Netzwerk zuordenbare Fehler einführt – insbesondere, wenn dem Zahlenden die Weiterleitungszeit an jedem Hop mitgeteilt wird. Unter Bezugnahme auf mehrere Arbeiten beschreibt sie zwei Arten von Deanonymisierungsangriffen:

  • ● Ein Angreifer, der einen oder mehrere Weiterleitungsknoten betreibt, nutzt Zeitdaten, um die Anzahl der Hops einer Zahlung (HTLC) zu bestimmen. Kombiniert mit Kenntnissen über die Topologie des öffentlichen Netzwerks kann dies die Menge möglicher Empfänger einschränken.

  • ● Ein Angreifer verwendet einen IP-Netzwerk-Traffic-Forwarder (autonomous system) zur passiven Überwachung des Traffics und kombiniert dies mit Kenntnissen über die IP-Latenz zwischen Knoten (Ping-Zeiten) sowie der Topologie und anderen Eigenschaften des öffentlichen Lightning Netzwerks.

  Sie beschreibt dann mögliche Gegenmaßnahmen, darunter:

  • Empfangende sollten das Akzeptieren eines HTLC um eine kleine, zufällige Zeit verzögern, um Timing-Angriffe zu erschweren, die den Empfänger identifizieren wollen.
  • ● Zahlende sollten das erneute Senden fehlgeschlagener Zahlungen (oder MPP-Teile) um eine kleine, zufällige Zeit verzögern und alternative Pfade nutzen, um Timing- und Fehlerangriffe zu erschweren, die den Zahlenden identifizieren wollen.
  • Mehr Zahlungssplitting mit MPP, um es schwieriger zu machen, den ausgegebenen Betrag zu erraten.
  • ● Zahlenden erlauben, sich für eine langsamere Weiterleitung ihrer Zahlungen zu entscheiden, wie zuvor vorgeschlagen (siehe Newsletter #208). Dies könnte mit HTLC-Batching kombiniert werden, das in LND bereits implementiert ist (eine zusätzliche zufällige Verzögerung könnte die Privatsphäre weiter erhöhen).
  • Die Genauigkeit der Zeitstempel von zuordenbaren Fehlern verringern, um Weiterleitungsknoten, die kleine Zufallsverzögerungen einbauen, nicht zu benachteiligen.

  Die Diskussion verschiedener Teilnehmer bewertete die Bedenken und vorgeschlagenen Gegenmaßnahmen im Detail und betrachtete weitere mögliche Angriffe und Gegenmaßnahmen.

Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange

Bitcoin Stack Exchange ist eine der ersten Anlaufstellen für Optech-Mitwirkende, wenn sie Antworten suchen – oder wenn wir ein paar Minuten Zeit haben, um neugierigen oder ratlosen Nutzern zu helfen. In dieser monatlichen Rubrik heben wir einige der am höchsten bewerteten Fragen und Antworten seit unserem letzten Update hervor.

• ● Welche Transaktionen gelangen in blockreconstructionextratxn? Glozow erklärt, wie die Extrapool-Datenstruktur (siehe Newsletter #339) abgelehnte und ersetzte Transaktionen, die vom Knoten gesehen wurden, zwischenspeichert und listet die Kriterien für Ausschluss und Entfernung auf.

• ● Warum sollte jemand OP_RETURN anstelle von Inscriptions verwenden, abgesehen von den Gebühren? Sjors Provoost merkt an, dass OP_RETURN nicht nur manchmal günstiger ist, sondern auch für Protokolle genutzt werden kann, die Daten benötigen, die vor dem Ausgeben einer Transaktion verfügbar sind – im Gegensatz zu Witness-Daten, die erst bei der Ausgabe offenbart werden.

• ● Warum erhält mein Bitcoin-Knoten keine eingehenden Verbindungen? Lightlike weist darauf hin, dass es bei einem neuen Knoten im Netzwerk einige Zeit dauern kann, bis seine Adresse im P2P-Netzwerk weit verbreitet ist, und dass Knoten ihre Adresse erst bewerben, wenn der Initial Block Download (IBD) abgeschlossen ist.

• ● Wie konfiguriere ich meinen Knoten so, dass er Transaktionen größer als 400 Byte herausfiltert? Antoine Poinsot bestätigt, dass es in Bitcoin Core keine Konfigurationsoption gibt, um die maximale Standard-Transaktionsgröße anzupassen. Er erläutert, dass Nutzer, die diesen Wert anpassen möchten, den Quellcode ändern können, warnt aber vor möglichen Nachteilen sowohl bei größeren als auch bei kleineren Maximalwerten.

• ● Was bedeutet „not publicly routable“ node im Bitcoin Core P2P? Pieter Wuille und Vasil Dimov geben Beispiele für P2P-Verbindungen, wie etwa Tor, die nicht über das globale Internet geroutet werden können und im netinfo-Output von Bitcoin Core im „npr“-Bucket erscheinen.

• ● Warum sollte ein Knoten überhaupt eine Transaktion weiterleiten? Pieter Wuille listet Vorteile für Betreiber auf, die Transaktionen weiterleiten: Privatsphäre beim Weiterleiten eigener Transaktionen, schnellere Blockverbreitung beim Mining und verbesserte Dezentralisierung des Netzwerks bei minimalen Zusatzkosten gegenüber dem bloßen Weiterleiten von Blöcken.

• ● Ist Selfish Mining mit Compact Blocks und FIBRE immer noch möglich? Antoine Poinsot antwortet auf eine Frage von 2016 und stellt klar: „Ja, Selfish Mining ist auch mit verbesserter Blockverbreitung weiterhin eine mögliche Optimierung. Es ist nicht korrekt zu sagen, dass Selfish Mining jetzt nur noch ein theoretischer Angriff ist.“ Er verweist außerdem auf eine von ihm erstellte Mining-Simulation.

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.

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

• ● LDK 0.1.3 und 0.1.4 sind Releases dieser beliebten Bibliothek zum Bau von LN-fähigen Anwendungen. Version 0.1.3, diese Woche als Release auf GitHub getaggt, aber letzten Monat datiert, enthält den Fix für einen Denial-of-Service-Angriff. Version 0.1.4, das aktuellste Release, „behebt eine Funds-Theft-Schwachstelle in extrem seltenen Fällen“. Beide Releases enthalten weitere Fehlerbehebungen.

Wichtige Code- und Dokumentationsänderungen

Bedeutende 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 #31622 fügt ein Signature-Hash-(sighash)-Typfeld zu PSBTs hinzu, wenn dieser Wert von SIGHASH_DEFAULT oder SIGHASH_ALL abweicht. MuSig2 erfordert, dass alle mit demselben Sighash-Typ signieren, daher muss dieses Feld in der PSBT vorhanden sein. Zusätzlich wird der RPC-Befehl descriptorprocesspsbt aktualisiert, sodass er die Funktion SignPSBTInput verwendet, die sicherstellt, dass der Sighash-Typ der PSBT mit dem in der CLI angegebenen Wert übereinstimmt, falls zutreffend.

• ● Eclair #3065 fügt Unterstützung für zuordenbare Fehler (siehe Newsletter #224) gemäß BOLTs #1044 hinzu. Diese Funktion ist standardmäßig deaktiviert, da die Spezifikation noch nicht final ist, kann aber mit der Einstellung eclair.features.option_attributable_failure = optional aktiviert werden. Die Kompatibilität mit LDK wurde erfolgreich getestet, siehe Newsletter #349 für weitere Informationen zur LDK-Implementierung und zum Protokoll.

• ● LDK #3796 verschärft die Überprüfung des Channel-Guthabens, sodass Finanzierer genügend Kapital für die Commitment-Transaktionsgebühr, die beiden 330 sat Anchor Outputs und die Channel-Reserve haben müssen. Zuvor konnten Finanzierer auf die Channel-Reserve zurückgreifen, um die beiden Anchor Outputs zu decken.

• ● BIPs #1760 merged BIP53, das eine Konsens-Softfork-Regel spezifiziert, die 64-Byte-Transaktionen (ohne Witness-Daten gemessen) verbietet, um eine Art von Merkle-Baum-Schwachstelle zu verhindern, die gegen SPV-Clients ausnutzbar wäre. Dieser PR schlägt eine ähnliche Korrektur wie eine der im Consensus Cleanup Softfork enthaltenen Korrekturen vor.

• ● BIPs #1850 macht eine frühere Änderung an BIP48 rückgängig, die den Script-Typ-Wert 3 für Taproot (P2TR)-Ableitungen reserviert hatte (siehe Newsletter #353). Grund ist, dass Tapscript kein OP_CHECKMULTISIG unterstützt, sodass das in BIP67 referenzierte Output-Skript (auf das sich BIP48 stützt) nicht als P2TR ausgedrückt werden kann. Der PR markiert außerdem den Status von BIP48 als „Final“, um widerzuspiegeln, dass der Zweck des BIPs die Definition der Branchenverwendung von m/48'-HD wallet-Ableitungspfaden war, nicht die Vorgabe neuen Verhaltens.

• ● BIPs #1793 merged BIP443, das den OP_CHECKCONTRACTVERIFY (OP_CCV)-Opcode vorschlägt, mit dem überprüft werden kann, dass ein öffentlicher Schlüssel (sowohl von Outputs als auch Inputs) auf beliebige Daten verpflichtet. Siehe Newsletter #348 für weitere Informationen zu diesem vorgeschlagenen Covenant.