Dieser Newsletter fasst eine Sicherheitslücke in älteren Eclair-Versionen sowie Forschungsergebnisse zu Feerate-Einstellungen von Full Nodes zusammen. Außerdem finden Sie wie gewohnt unsere Abschnitte mit ausgewählten Fragen & Antworten von Bitcoin Stack Exchange, Ankündigungen zu neuen Releases und Release Kandidaten sowie bemerkenswerte Änderungen an verbreiteter Bitcoin-Infrastruktur-Software.

Nachrichten

• ● Eclair-Sicherheitslücke: Matt Morehouse postete auf Delving Bitcoin eine verantwortungsvolle Offenlegung (responsible disclosure) einer Sicherheitslücke in älteren Eclair-Versionen. Allen Eclair-Nutzern wird empfohlen, auf Version 0.12 oder neuer zu aktualisieren. Die Lücke ermöglichte es einem Angreifer, eine alte Commitment-Transaktion zu veröffentlichen und so alle aktuellen Mittel eines Kanals zu stehlen. Neben der Behebung der Lücke haben die Eclair-Entwickler eine umfangreiche Test-Suite hinzugefügt, um ähnliche Fehler künftig früher zu erkennen.

• ● Untersuchung zu Feerate-Einstellungen: Daniela Brozzoni veröffentlichte auf Delving Bitcoin die Ergebnisse eines Scans von fast 30.000 Full Nodes, die eingehende Verbindungen akzeptierten. Jeder Knoten wurde nach dem BIP133 Fee-Filter befragt, der die niedrigste Feerate angibt, bei welcher der Knoten aktuell unbestätigte, weitergeleitete Transaktionen akzeptiert. Solange die Mempools nicht voll sind, entspricht dies dem standardmäßigen minimalen Relay-Feerate des Knotens. Die Auswertung zeigt, dass die meisten Knoten den bisherigen Standard von 1 sat/vbyte (s/v) verwenden. Etwa 4 % der Knoten nutzten 0,1 s/v, den Standard der kommenden Bitcoin Core 30.0, und rund 8 % antworteten gar nicht auf die Abfrage – was auf sogenannte Spy-Nodes hindeuten kann.

  Ein kleiner Anteil der Knoten gab den Wert 9.170.997 (10.000 s/v) als Feefilter an; Entwickler 0xB10C merkte an, dass Bitcoin Core diesen, durch Rundung entstandenen, Wert setzt, wenn der Knoten mehr als 100 Blöcke hinter dem Tip liegt und sich auf den Empfang von Blockdaten statt auf Transaktionen konzentriert, die in späteren Blöcken bestätigt werden könnten.

Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange

Bitcoin Stack Exchange ist eine der ersten Anlaufstellen für Optech-Beitragende, wenn sie nach Antworten suchen – oder um in kurzen Pausen fragenden Nutzern zu helfen. In diesem monatlichen Beitrag heben wir einige der am besten bewerteten Fragen und Antworten seit unserem letzten Update hervor.

• ● Auswirkungen der OP_RETURN-Änderungen in der kommenden Bitcoin Core-Version 30.0? Pieter Wuille erläutert seine Sicht auf Vor- und Nachteile der Nutzung von Mempool- und Relay-Policy, um den Inhalt geminter Blöcke zu beeinflussen (policy series).

• ● Wenn OP_RETURN-Relay-Limits unwirksam sind: Warum das Schutzmittel entfernen statt es als Standardabschreckung zu belassen? Antoine Poinsot erklärt den Fehlanreiz, den der aktuelle Standardwert für OP_RETURN in Bitcoin Core erzeugt, und die Gründe für dessen Entfernung.

• ● Was sind Worst-Case-Stress-Szenarien durch unbeschränkte OP_RETURNs in Bitcoin Core v30? Vojtěch Strnad und Pieter Wuille gehen auf eine Liste extremer Szenarien ein, die durch die Änderung der Standard-Policy für OP_RETURN entstehen könnten.

• ● Wenn OP_RETURN mehr Platz gebraucht hätte: Warum wurde das 80-Byte-Limit entfernt statt auf 160 erhöht? Ava Chow und Antoine Poinsot führen Gründe gegen einen Standardwert von 160 Bytes an, darunter die Abneigung, das Limit ständig anheben zu müssen, dass große Miner das Limit ohnehin umgehen, und Risiken, künftige On-Chain-Aktivität nicht ausreichend zu antizipieren.

• ● Wenn beliebige Daten unvermeidlich sind: Führt das Entfernen des OP_RETURN-Limits zu mehr schädlichen Speicherpraktiken (z. B. UTXO-aufblähende Adressen)? Ava Chow weist darauf hin, dass das Entfernen des OP_RETURN-Limits Anreize schafft, für bestimmte Anwendungsfälle eine weniger schädliche Alternative zur Speicherung von Ausgabedaten zu nutzen.

• ● Wenn OP_RETURN-Uncapping das UTXO-Set nicht vergrößert: Wie trägt es trotzdem zu Blockchain-Bloat und Zentralisierungsdruck bei? Ava Chow erklärt, wie vermehrte Nutzung von OP_RETURN-Ausgaben die Ressourcenbelastung von Bitcoin-Knoten erhöht.

• ● Wie beeinflusst das Aufheben der OP_RETURN-Begrenzung die langfristige Qualität des Fee-Markts und das Security-Budget? Ava Chow beantwortet mehrere Fragen zu hypothetischer OP_RETURN-Nutzung und deren Auswirkungen auf zukünftige Mining-Einnahmen.

• ● Ist die Blockchain vor illegalen Inhalten bei 100KB OP_RETURN geschützt? Nutzer jb55 liefert mehrere Beispiele möglicher Kodierschemata und kommt zu dem Schluss: “Nein, im Allgemeinen kann man solche Dinge in einem zensurresistenten, dezentralen Netzwerk nicht wirklich verhindern.”

• ● Welche Analyse zeigt, dass OP_RETURN-Uncapping die Block-Propagation oder das Orphan-Risiko nicht verschlechtert? Ava Chow weist darauf hin, dass es zwar keinen Datensatz gibt, der speziell große OP_RETURNs isoliert, frühere Analysen zu compact blocks und Stale-Blocks jedoch keinen Grund liefern, ein anderes Verhalten zu erwarten.

• ● Wo speichert Bitcoin Core die XOR-Obfuskationsschlüssel für Blockdaten-Dateien und LevelDB-Indizes? Vojtěch Strnad erklärt, dass der Chainstate-Schlüssel in LevelDB unter dem Schlüssel “\000obfuscate_key” liegt, während der Schlüssel für Block- und Undo-Daten in der Datei blocks/xor.dat gespeichert wird.

• ● Wie robust ist der 1p1c-Transaction-Relay in Bitcoin Core 28.0? Glozow stellt klar, dass mit “nicht robust” in dem ursprünglichen PR zum opportunistischen “one parent one child (1P1C) relay” gemeint ist, dass das Verhalten nicht garantiert funktioniert, besonders in Gegenwart von Angreifern oder bei sehr hohem Transaktionsaufkommen.

• ● Wie kann ich getblocktemplate erlauben, Transaktionen unter 1 sat/vbyte einzuschließen? Nutzer inersha beschreibt die nötigen Einstellungen, um nicht nur sub-1-sat/vbyte Transaktionen weiterzuleiten, sondern diese auch in einem Kandidatenblock-Template aufzunehmen.

Releases und Release-Kandidaten

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

• ● Bitcoin Core 30.0rc1 ist ein Release Candidate für die nächste Hauptversion der vollständigen Verifikations-Knoten-Software. Siehe bitte den Testing-Guide für Version 30.

Wichtige Code- und Dokumentationsänderungen

Bemerkenswerte Ä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 #33333 gibt nun eine Startwarnung aus, wenn die dbcache Einstellung eines Knotens einen Schwellenwert überschreitet, der aus dem verfügbaren Arbeitsspeicher des Systems abgeleitet wird. Das soll Out-of-Memory-Fehler oder intensives Swapping verhindern. Für Systeme mit weniger als 2 GB RAM liegt die dbcache-Warnschwelle bei 450 MB; andernfalls beträgt die Schwelle 75 % des gesamten RAM. Das frühere dbcache-Limit von 16 GB wurde im September 2024 entfernt (siehe Newsletter #321).

• ● Bitcoin Core #28592 erhöht die pro-Peer-Transaktions-Relay-Rate für eingehende Verbindungen von 7 auf 14, um der gestiegenen Präsenz kleinerer Transaktionen im Netzwerk Rechnung zu tragen. Für ausgehende Peers ist die Rate 2,5-mal höher und steigt auf 35 Transaktionen pro Sekunde. Die Relay-Rate begrenzt, wie viele Transaktionen ein Knoten seinen Peers sendet.

• ● Eclair #3171 entfernt PaymentWeightRatios, eine Pfadfindungsmethode, die Uniformität in Kanal-Balances annahm, und ersetzt sie durch einen neu eingeführten probabilistischen Ansatz, der auf vergangenen Zahlungsversuchen basiert (siehe Newsletter #371).

• ● Eclair #3175 lehnt nun unbezahllbare BOLT12 Offers ab, bei denen die Felder offer_chains, offer_paths, invoice_paths und invoice_blindedpay vorhanden, aber leer sind.

• ● LDK #4064 aktualisiert die Signaturprüfungslogik, sodass, wenn das Feld n (Payee-Pubkey) vorhanden ist, die Signatur gegen diesen Wert verifiziert wird. Andernfalls wird der Pubkey des Empfängers aus der BOLT11 Invoice extrahiert; sowohl High-S- als auch Low-S-Signaturen werden berücksichtigt. Dieser PR bringt die Prüfungen in Einklang mit dem vorgeschlagenen BOLTs #1284 und anderen Implementierungen wie Eclair (siehe Newsletter #371).

• ● LDK #4067 fügt Unterstützung dafür hinzu, P2A ephemeral anchor Ausgaben aus zero-fee commitment Transaktionen auszugeben, sodass Kanalpartner ihre Mittel on-chain zurückfordern können. Siehe Newsletter #371 für LDKs Implementierung von Zero-Fee-Commitment-Kanälen.

• ● LDK #4046 ermöglicht es einem häufig offline befindlichen Sender, async payments an einen häufig offline befindlichen Empfänger zu senden. Der Sender setzt ein Flag in der update_add_htlc Nachricht, damit das HTLC beim LSP gehalten wird, bis der Empfänger wieder online ist und eine release_held_htlc Onion-Nachricht sendet, um die Zahlung zu beanspruchen.

• ● LDK #4083 markiert den Endpoint pay_for_offer_from_human_readable_name als veraltet, um doppelte BIP353 HRN-Zahlungs-APIs zu entfernen. Wallets sollten die bitcoin-payment-instructions-Crate verwenden, um Zahlungsanweisungen zu parsen und aufzulösen, bevor sie pay_for_offer_from_hrn aufrufen (z. B. satoshi@nakamoto.com).

• ● LND #10189 aktualisiert sein sweeper-System (siehe Newsletter #346), sodass der Fehlercode ErrMinRelayFeeNotMet korrekt erkannt wird und fehlgeschlagene Transaktionen durch erneutes Senden mit erhöhter Gebühr (Fee Bumping) solange neu versucht werden, bis die Übertragung erfolgreich ist. Zuvor wurde der Fehler falsch zugeordnet, sodass kein Retry erfolgte. Außerdem verbessert der PR die Gewichtsschätzung, indem ein mögliches zusätzliches Change-Output berücksichtigt wird; relevant für Taproot-Overlay-Kanäle und LNDs Taproot Assets.

• ● BIPs #1963 ändert den Status der BIPs, die kompakte Blockfilter spezifizieren (BIP157 und BIP158) von Draft zu Final, da sie seit 2020 in Bitcoin Core und anderer Software eingesetzt werden.