From 068b1b58648c7a60e933e44c7e2b127681a5f09e Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Sun, 2 Feb 2025 13:05:12 +0100 Subject: [PATCH 1/6] Add German translation for Newsletter #339 --- .../de/newsletters/2025-01-31-newsletter.md | 276 ++++++++++++++++++ 1 file changed, 276 insertions(+) create mode 100644 _posts/de/newsletters/2025-01-31-newsletter.md diff --git a/_posts/de/newsletters/2025-01-31-newsletter.md b/_posts/de/newsletters/2025-01-31-newsletter.md new file mode 100644 index 0000000000..0b430dd347 --- /dev/null +++ b/_posts/de/newsletters/2025-01-31-newsletter.md @@ -0,0 +1,276 @@ +--- +title: 'Bitcoin Optech Newsletter #339' +permalink: /de/newsletters/2025/01/31/ +name: 2025-01-31-newsletter-de +slug: 2025-01-31-newsletter-de +type: newsletter +layout: newsletter +lang: de +--- +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][morehouse ldkclaim], in dem + er eine Schwachstelle in LDK aufdeckte – eine Schwachstelle, die er [verantwortungsvoll + offengelegt][topic responsible disclosures] hat und die in LDK Version 0.1 behoben wurde. + + Wenn ein Kanal einseitig geschlossen wird und dabei mehrere ausstehende [HTLCs][topic htlc] + 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. In diesem Fall erstellt LDK korrekt eine + aktualisierte Sammeltransaktion, in der der Konflikt entfernt wurde. Unglücklicherweise + aktualisiert LDK, falls die Transaktion der Gegenpartei mit mehreren separaten + Sammeltransaktionen in Konflikt steht, fälschlicherweise nur die erste, sodass die übrigen 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][topic timelocks] 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][news335 + ldk3340]) 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][riard + minecycle], um eine weitere Schwachstelle offenzulegen, die mit dem [Replacement + Cycling][topic replacement cycling] Angriff möglich ist – einem Angriff, den er ursprünglich + 2023 öffentlich bekannt machte (siehe [Newsletter #274][news274 cycle]). + + Kurz zusammengefasst: + + 1. Bob sendet eine Transaktion, in der er an Mallory (und möglicherweise an weitere Empfänger) + zahlt. + + 2. Mallory [pinnt][topic transaction pinning] Bobs Transaktion. + + 3. Bob bemerkt nicht, dass seine Transaktion gepinnt wurde, und erhöht die Gebühren (entweder + mittels [RBF][topic rbf] oder [CPFP][topic 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][miningpool.observer] entwickeln und einsetzen, erkannt wird. + +- **Aktualisierte Statistiken zur Kompaktblock-Rekonstruktion:** + Auf einen vorherigen Thread (siehe [Newsletter #315][news315 cb]) 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][topic compact block relay]-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][news338 orphan]), 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][bitcoin.se] 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.* + +{% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Wer nutzt oder möchte PSBTv2 (BIP370) verwenden?](../../en/newsletters/{{bse}}125384) + Neben seinem Posting in der Bitcoin-Dev-Mailingliste (siehe [Newsletter #338][news338 psbtv2]) + hat Sjors Provoost auch im Bitcoin Stack Exchange nach Nutzern und potenziellen Anwendern von + [PSBTv2][topic psbt] gesucht. Leser von Optech, die an [BIP370][] interessiert sind, werden + gebeten, auf die Frage oder den entsprechenden Mailinglisten-Beitrag zu antworten. + +- [Im Bitcoin-Genesisblock, welche Teile können beliebig belegt werden?](../../en/newsletters/{{bse}}125274) + Pieter Wuille weist darauf hin, dass keines der Felder des [Genesis-Blocks][mempool genesis + block] den üblichen Blockvalidierungsregeln unterliegt. Er erklärt: "Buchstäblich alle könnten + jeglichen Inhalt enthalten haben. Dort, wo es möglich war, wurde es wie ein normaler Block + gestaltet – es hätte aber auch anders sein können." + +- [Erkennung von Lightning-Force-Close](../../en/newsletters/{{bse}}122504) + Sanket1729 und Antoine Poinsot diskutieren, wie der [Block-Explorer][topic block explorers] von + mempool.space die Felder [`nLockTime`][topic timelocks] und `nSequence` verwendet, um + festzustellen, ob eine Transaktion eine Lightning force close Transaktion ist. + +- [Ist eine segwit-formatierte Transaktion mit allen Eingaben vom Typ + „Nicht-Witness-Programm" gültig?](../../en/newsletters/{{bse}}125240) + Pieter Wuille unterscheidet zwischen [BIP141][], das die Struktur und Gültigkeit im + Zusammenhang mit den Segwit-Konsensänderungen und der Berechnung von wtxids festlegt, und + [BIP144][], das das Serialisierungsformat für die Übertragung von Segwit-Transaktionen + definiert. + +- [P2TR-Sicherheitsfrage](../../en/newsletters/{{bse}}125334) + Pieter Wuille zitiert aus [BIP341][], das [Taproot][topic taproot] spezifiziert, um zu + erklären, warum ein öffentlicher Schlüssel direkt in einer Ausgabe enthalten ist, und geht auf + damit verbundene Überlegungen zum Thema Quantencomputing ein. + +- [Was genau wird heute unternommen, um Bitcoin quantensicher zu machen?](../../en/newsletters/{{bse}}125171) + Murch kommentiert den aktuellen Stand der quantentechnologischen Fähigkeiten, kürzlich + eingeführte [post-quantum Signaturschemata][topic quantum resistance] und den vorgeschlagenen + [QuBit – Pay to Quantum Resistant Hash][BIPs #1670]-BIP. + +- [Welche schädlichen Auswirkungen hat eine kürzere Inter-Block-Zeit?](../../en/newsletters/{{bse}}125318) + Pieter Wuille hebt den Vorteil hervor, den ein Miner aufgrund der Blockpropagation erlangt, + kurz nachdem er einen Block gefunden hat, wie dieser Vorteil bei kürzeren Blockzeiten verstärkt + wird und welche potenziellen Auswirkungen daraus resultieren können. + +- [Kann Proof-of-Work eingesetzt werden, um Richtlinienregeln zu ersetzen?](../../en/newsletters/{{bse}}124931) + Jgmontoya fragt sich, ob das Anhängen von Proof-of-Work an nicht-standardmäßige Transaktionen + ähnliche Ziele des [Schutzes von Node-Ressourcen][policy series] erreichen könnte wie die + Mempool-Policy. Antoine Poinsot weist darauf hin, dass die Mempool-Policy neben dem Schutz der + Node-Ressourcen auch weitere Ziele verfolgt – etwa eine effiziente Erstellung von + Blocktemplates, das Abschrecken bestimmter Transaktionstypen und den Schutz von Upgrade-Hooks + bei [Soft Forks][topic soft fork activation]. + +- [Wie funktioniert MuSig in realen Bitcoin-Szenarien?](../../en/newsletters/{{bse}}125030) + Pieter Wuille erläutert die Unterschiede zwischen den [MuSig][topic musig]-Versionen, hebt die + Interactive Aggregated Signature (IAS)-Variante von MuSig1 und deren Zusammenspiel mit der + [Cross-Input-Signaturaggregation (CISA)][topic cisa] hervor und erwähnt [Threshold + Signatures][topic threshold signature], bevor er detailliertere Fragen zu den Spezifikationen + beantwortet. + +- [Wie funktioniert der -blocksxor-Schalter, der die blocks.dat-Dateien + verschleiert?](../../en/newsletters/{{bse}}125055) + Vojtěch Strnad beschreibt die `-blocksxor`-Option zum Verschleiern der Bitcoin Core + Blockdaten-Dateien auf der Festplatte (siehe [Newsletter #316][news316 xor]). + +- [Wie funktioniert der Related-Key-Angriff auf Schnorr-Signaturen?](../../en/newsletters/{{bse}}125328) + Pieter Wuille erklärt, dass „der Angriff anwendbar ist, wenn das Opfer einen verwandten + Schlüssel auswählt und der Angreifer die Beziehung kennt" und dass verwandte Schlüssel äußerst + verbreitet sind. + +## 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][morehouse ldk-dos]; 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][bitcoin core repo], [Core Lightning][core +lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 +repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], +[Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin +inquisition repo] und [BINANAs][binana repo]._ + +- [Bitcoin Core #31376][] erweitert eine Prüfung, die verhindert, dass Miner Blockvorlagen + erstellen, welche den [Timewarp][topic time warp]-Fehler ausnutzen – und zwar für alle + Netzwerke, nicht nur für [testnet4][topic testnet]. 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][topic pooled mining]. + +- [Bitcoin Core #31590][] überarbeitet die Methode `GetPrivKey()`, sodass beim Abrufen privater + Schlüssel für einen [x-only-Pubkey][topic x-only public keys] in einem [Descriptor][topic + descriptors] 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][topic 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][topic compact + block filters] 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][topic 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][news238 peer]) und Eclair (siehe Newsletter + [#335][news335 peer]) implementiert. + +{% include snippets/recap-ad.md when="2025-02-04 15:30" %} +{% include references.md %} +{% include linkers/issues.md v=2 issues="31376,31583,31590,2982,1614,1110,1670" %} +[morehouse ldkclaim]: https://delvingbitcoin.org/t/disclosure-ldk-invalid-claims-liquidity-griefing/1400 +[news335 ldk3340]: /en/newsletters/2025/01/03/#ldk-3340 +[riard minecycle]: https://mailing-list.bitcoindevs.xyz/bitcoindev/CALZpt+EnDUtfty3X=u2-2c5Q53Guc6aRdx0Z4D75D50ZXjsu2A@mail.gmail.com/ +[miningpool.observer]: https://miningpool.observer/template-and-block +[b10c cb]: https://delvingbitcoin.org/t/stats-on-compact-block-reconstructions/1052/5 +[news315 cb]: /en/newsletters/2024/08/09/#statistics-on-compact-block-reconstruction +[news338 orphan]: /en/newsletters/2025/01/24/#bitcoin-core-31397 +[news274 cycle]: /en/newsletters/2023/10/25/#replacement-cycling-vulnerability-against-htlcs +[ldk v0.1.1]: https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.1.1 +[morehouse ldk-dos]: https://delvingbitcoin.org/t/disclosure-ldk-duplicate-htlc-force-close-griefing/1410 +[news281 griefing]: /en/newsletters/2023/12/13/#discussion-about-griefing-liquidity-ads +[news238 peer]: /en/newsletters/2023/02/15/#core-lightning-5361 +[news335 peer]: /en/newsletters/2025/01/03/#eclair-2888 +[news338 psbtv2]: /en/newsletters/2025/01/24/#psbtv2-integration-testing +[mempool genesis block]: https://mempool.space/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f +[policy series]: /en/blog/waiting-for-confirmation/#policy-for-protection-of-node-resources +[news316 xor]: /en/newsletters/2024/08/16/#bitcoin-core-28052 From 646169363671afca2e5ee676eb66317f16c13739 Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Sun, 2 Feb 2025 13:27:01 +0100 Subject: [PATCH 2/6] Fix broken links in German translation of Newsletter #339 --- .../de/newsletters/2025-01-31-newsletter.md | 53 +++++++++---------- 1 file changed, 25 insertions(+), 28 deletions(-) diff --git a/_posts/de/newsletters/2025-01-31-newsletter.md b/_posts/de/newsletters/2025-01-31-newsletter.md index 0b430dd347..b53e43726a 100644 --- a/_posts/de/newsletters/2025-01-31-newsletter.md +++ b/_posts/de/newsletters/2025-01-31-newsletter.md @@ -19,8 +19,8 @@ Bitcoin-Infrastruktursoftware beschrieben werden. - **Sicherheitslücke in der LDK-HTLC-Abwicklung:** Matt Morehouse hat auf Delving Bitcoin einen Beitrag [veröffentlicht][morehouse ldkclaim], in dem - er eine Schwachstelle in LDK aufdeckte – eine Schwachstelle, die er [verantwortungsvoll - offengelegt][topic responsible disclosures] hat und die in LDK Version 0.1 behoben wurde. + er eine Schwachstelle in LDK aufdeckte – eine Schwachstelle, die er + [verantwortungsvoll offengelegt][topic responsible disclosures] hat und die in LDK Version 0.1 behoben wurde. Wenn ein Kanal einseitig geschlossen wird und dabei mehrere ausstehende [HTLCs][topic htlc] vorhanden sind, versucht LDK, möglichst viele HTLCs in einer einzigen Sammeltransaktion @@ -44,8 +44,8 @@ Bitcoin-Infrastruktursoftware beschrieben werden. 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][news335 - ldk3340]) und begann damit, alle Arten von HTLCs zusammenzufassen, wodurch ein Angreifer in die + Der Release-Kandidat LDK 0.1-beta änderte jedoch seine Logik (siehe [Newsletter #335][news335 ldk3340]) + 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. @@ -54,9 +54,9 @@ Bitcoin-Infrastruktursoftware beschrieben werden. 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][riard - minecycle], um eine weitere Schwachstelle offenzulegen, die mit dem [Replacement - Cycling][topic replacement cycling] Angriff möglich ist – einem Angriff, den er ursprünglich + Antoine Riard hat auf der Bitcoin-Dev-Mailingliste einen Beitrag [veröffentlicht][riard minecycle], + um eine weitere Schwachstelle offenzulegen, die mit dem [Replacement Cycling][topic replacement cycling] + Angriff möglich ist – einem Angriff, den er ursprünglich 2023 öffentlich bekannt machte (siehe [Newsletter #274][news274 cycle]). Kurz zusammengefasst: @@ -131,8 +131,8 @@ bestbewerteten Fragen und Antworten hervor, die seit unserem letzten Update gepo gebeten, auf die Frage oder den entsprechenden Mailinglisten-Beitrag zu antworten. - [Im Bitcoin-Genesisblock, welche Teile können beliebig belegt werden?](../../en/newsletters/{{bse}}125274) - Pieter Wuille weist darauf hin, dass keines der Felder des [Genesis-Blocks][mempool genesis - block] den üblichen Blockvalidierungsregeln unterliegt. Er erklärt: "Buchstäblich alle könnten + Pieter Wuille weist darauf hin, dass keines der Felder des [Genesis-Blocks][mempool genesis block] + den üblichen Blockvalidierungsregeln unterliegt. Er erklärt: "Buchstäblich alle könnten jeglichen Inhalt enthalten haben. Dort, wo es möglich war, wurde es wie ein normaler Block gestaltet – es hätte aber auch anders sein können." @@ -141,8 +141,7 @@ bestbewerteten Fragen und Antworten hervor, die seit unserem letzten Update gepo mempool.space die Felder [`nLockTime`][topic timelocks] und `nSequence` verwendet, um festzustellen, ob eine Transaktion eine Lightning force close Transaktion ist. -- [Ist eine segwit-formatierte Transaktion mit allen Eingaben vom Typ - „Nicht-Witness-Programm" gültig?](../../en/newsletters/{{bse}}125240) +- [Ist eine segwit-formatierte Transaktion mit allen Eingaben vom Typ „Nicht-Witness-Programm" gültig?](../../en/newsletters/{{bse}}125240) Pieter Wuille unterscheidet zwischen [BIP141][], das die Struktur und Gültigkeit im Zusammenhang mit den Segwit-Konsensänderungen und der Berechnung von wtxids festlegt, und [BIP144][], das das Serialisierungsformat für die Übertragung von Segwit-Transaktionen @@ -174,12 +173,10 @@ bestbewerteten Fragen und Antworten hervor, die seit unserem letzten Update gepo - [Wie funktioniert MuSig in realen Bitcoin-Szenarien?](../../en/newsletters/{{bse}}125030) Pieter Wuille erläutert die Unterschiede zwischen den [MuSig][topic musig]-Versionen, hebt die Interactive Aggregated Signature (IAS)-Variante von MuSig1 und deren Zusammenspiel mit der - [Cross-Input-Signaturaggregation (CISA)][topic cisa] hervor und erwähnt [Threshold - Signatures][topic threshold signature], bevor er detailliertere Fragen zu den Spezifikationen - beantwortet. + [Cross-Input-Signaturaggregation (CISA)][topic cisa] hervor und erwähnt [Threshold Signatures][topic threshold signature], + bevor er detailliertere Fragen zu den Spezifikationen beantwortet. -- [Wie funktioniert der -blocksxor-Schalter, der die blocks.dat-Dateien - verschleiert?](../../en/newsletters/{{bse}}125055) +- [Wie funktioniert der -blocksxor-Schalter, der die blocks.dat-Dateien verschleiert?](../../en/newsletters/{{bse}}125055) Vojtěch Strnad beschreibt die `-blocksxor`-Option zum Verschleiern der Bitcoin Core Blockdaten-Dateien auf der Festplatte (siehe [Newsletter #316][news316 xor]). @@ -198,19 +195,19 @@ helfen._ 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][morehouse ldk-dos]; Optech wird in der nächsten Ausgabe des Newsletters eine - detailliertere Zusammenfassung liefern. Das Release beinhaltet außerdem API-Updates und - Fehlerbehebungen. + Morehouse, der die Schwachstelle entdeckt hat, + [hat darüber bei Delving Bitcoin berichtet][morehouse ldk-dos]; + 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][bitcoin core repo], [Core Lightning][core -lightning repo], [Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 -repo], [Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay -Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], -[Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin -inquisition repo] und [BINANAs][binana repo]._ +_Wichtige aktuelle Änderungen in [Bitcoin Core][bitcoin core repo], [Core Lightning][core lightning repo], +[Eclair][eclair repo], [LDK][ldk repo], [LND][lnd repo], [libsecp256k1][libsecp256k1 repo], +[Hardware Wallet Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay Server][btcpay server repo], +[BDK][bdk repo], [Bitcoin Improvement Proposals (BIPs)][bips repo], +[Lightning BOLTs][bolts repo], [Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition repo] und +[BINANAs][binana repo]._ - [Bitcoin Core #31376][] erweitert eine Prüfung, die verhindert, dass Miner Blockvorlagen erstellen, welche den [Timewarp][topic time warp]-Fehler ausnutzen – und zwar für alle @@ -226,8 +223,8 @@ inquisition repo] und [BINANAs][binana repo]._ Änderungen sind nützlich für die Implementierung von [Stratum V2][topic pooled mining]. - [Bitcoin Core #31590][] überarbeitet die Methode `GetPrivKey()`, sodass beim Abrufen privater - Schlüssel für einen [x-only-Pubkey][topic x-only public keys] in einem [Descriptor][topic - descriptors] beide möglichen Werte des Paritätsbits überprüft werden. Zuvor konnte, wenn der + Schlüssel für einen [x-only-Pubkey][topic x-only public keys] in einem [Descriptor][topic descriptors] + 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. From 7e996c131516773913c99ddd8e5baca5cff4781f Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Sun, 2 Feb 2025 13:36:10 +0100 Subject: [PATCH 3/6] fix dobble words der/das --- .../de/newsletters/2025-01-31-newsletter.md | 22 ++++++++----------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/_posts/de/newsletters/2025-01-31-newsletter.md b/_posts/de/newsletters/2025-01-31-newsletter.md index b53e43726a..05f2f306e4 100644 --- a/_posts/de/newsletters/2025-01-31-newsletter.md +++ b/_posts/de/newsletters/2025-01-31-newsletter.md @@ -17,7 +17,7 @@ Bitcoin-Infrastruktursoftware beschrieben werden. ## News -- **Sicherheitslücke in der LDK-HTLC-Abwicklung:** +- **Sicherheitslücke in der LDK-HTLC-Abwicklung:** Matt Morehouse hat auf Delving Bitcoin einen Beitrag [veröffentlicht][morehouse ldkclaim], in dem er eine Schwachstelle in LDK aufdeckte – eine Schwachstelle, die er [verantwortungsvoll offengelegt][topic responsible disclosures] hat und die in LDK Version 0.1 behoben wurde. @@ -26,11 +26,10 @@ Bitcoin-Infrastruktursoftware beschrieben werden. 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. In diesem Fall erstellt LDK korrekt eine - aktualisierte Sammeltransaktion, in der der Konflikt entfernt wurde. Unglücklicherweise - aktualisiert LDK, falls die Transaktion der Gegenpartei mit mehreren separaten - Sammeltransaktionen in Konflikt steht, fälschlicherweise nur die erste, sodass die übrigen nicht - bestätigt werden können. + 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][topic timelocks] verhindert, @@ -53,14 +52,14 @@ Bitcoin-Infrastruktursoftware beschrieben werden. 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:** +- **Angriffe durch Replacement Cycling mit Ausnutzung von Minern:** Antoine Riard hat auf der Bitcoin-Dev-Mailingliste einen Beitrag [veröffentlicht][riard minecycle], um eine weitere Schwachstelle offenzulegen, die mit dem [Replacement Cycling][topic replacement cycling] Angriff möglich ist – einem Angriff, den er ursprünglich 2023 öffentlich bekannt machte (siehe [Newsletter #274][news274 cycle]). Kurz zusammengefasst: - + 1. Bob sendet eine Transaktion, in der er an Mallory (und möglicherweise an weitere Empfänger) zahlt. @@ -88,7 +87,7 @@ Bitcoin-Infrastruktursoftware beschrieben werden. regelmäßig ausnutzen, gehen wir davon aus, dass sein Verhalten von Community-Mitgliedern, die [Block-Monitoring-Tools][miningpool.observer] entwickeln und einsetzen, erkannt wird. -- **Aktualisierte Statistiken zur Kompaktblock-Rekonstruktion:** +- **Aktualisierte Statistiken zur Kompaktblock-Rekonstruktion:** Auf einen vorherigen Thread (siehe [Newsletter #315][news315 cb]) 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 @@ -142,10 +141,7 @@ bestbewerteten Fragen und Antworten hervor, die seit unserem letzten Update gepo festzustellen, ob eine Transaktion eine Lightning force close Transaktion ist. - [Ist eine segwit-formatierte Transaktion mit allen Eingaben vom Typ „Nicht-Witness-Programm" gültig?](../../en/newsletters/{{bse}}125240) - Pieter Wuille unterscheidet zwischen [BIP141][], das die Struktur und Gültigkeit im - Zusammenhang mit den Segwit-Konsensänderungen und der Berechnung von wtxids festlegt, und - [BIP144][], das das Serialisierungsformat für die Übertragung von Segwit-Transaktionen - definiert. + Pieter Wuille unterscheidet zwischen [BIP141][], das die Struktur und Gültigkeit im Zusammenhang mit den Segwit-Konsensänderungen und der Berechnung von wtxids bestimmt, und [BIP144][], welches das Serialisierungsformat für die Übertragung von Segwit-Transaktionen definiert. - [P2TR-Sicherheitsfrage](../../en/newsletters/{{bse}}125334) Pieter Wuille zitiert aus [BIP341][], das [Taproot][topic taproot] spezifiziert, um zu From 5ae76363a17911e400b092ab76d534b42461c014 Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Sun, 2 Feb 2025 13:43:55 +0100 Subject: [PATCH 4/6] fix space --- _posts/de/newsletters/2025-01-31-newsletter.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_posts/de/newsletters/2025-01-31-newsletter.md b/_posts/de/newsletters/2025-01-31-newsletter.md index 05f2f306e4..4c01f779a9 100644 --- a/_posts/de/newsletters/2025-01-31-newsletter.md +++ b/_posts/de/newsletters/2025-01-31-newsletter.md @@ -17,7 +17,7 @@ Bitcoin-Infrastruktursoftware beschrieben werden. ## News -- **Sicherheitslücke in der LDK-HTLC-Abwicklung:** +- **Sicherheitslücke in der LDK-HTLC-Abwicklung:** Matt Morehouse hat auf Delving Bitcoin einen Beitrag [veröffentlicht][morehouse ldkclaim], in dem er eine Schwachstelle in LDK aufdeckte – eine Schwachstelle, die er [verantwortungsvoll offengelegt][topic responsible disclosures] hat und die in LDK Version 0.1 behoben wurde. @@ -52,14 +52,14 @@ Bitcoin-Infrastruktursoftware beschrieben werden. 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:** +- **Angriffe durch Replacement Cycling mit Ausnutzung von Minern:** Antoine Riard hat auf der Bitcoin-Dev-Mailingliste einen Beitrag [veröffentlicht][riard minecycle], um eine weitere Schwachstelle offenzulegen, die mit dem [Replacement Cycling][topic replacement cycling] Angriff möglich ist – einem Angriff, den er ursprünglich 2023 öffentlich bekannt machte (siehe [Newsletter #274][news274 cycle]). Kurz zusammengefasst: - + 1. Bob sendet eine Transaktion, in der er an Mallory (und möglicherweise an weitere Empfänger) zahlt. @@ -87,7 +87,7 @@ Bitcoin-Infrastruktursoftware beschrieben werden. regelmäßig ausnutzen, gehen wir davon aus, dass sein Verhalten von Community-Mitgliedern, die [Block-Monitoring-Tools][miningpool.observer] entwickeln und einsetzen, erkannt wird. -- **Aktualisierte Statistiken zur Kompaktblock-Rekonstruktion:** +- **Aktualisierte Statistiken zur Kompaktblock-Rekonstruktion:** Auf einen vorherigen Thread (siehe [Newsletter #315][news315 cb]) 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 From 4cfd64d03a47a19ed4cbcb6a13a9e673c89193df Mon Sep 17 00:00:00 2001 From: Walpurga03 Date: Sun, 2 Feb 2025 13:59:34 +0100 Subject: [PATCH 5/6] link relativen Pfad --- .../de/newsletters/2025-01-31-newsletter.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/_posts/de/newsletters/2025-01-31-newsletter.md b/_posts/de/newsletters/2025-01-31-newsletter.md index 4c01f779a9..92beeb38af 100644 --- a/_posts/de/newsletters/2025-01-31-newsletter.md +++ b/_posts/de/newsletters/2025-01-31-newsletter.md @@ -123,42 +123,42 @@ bestbewerteten Fragen und Antworten hervor, die seit unserem letzten Update gepo {% comment %}{% endcomment %} {% assign bse = "https://bitcoin.stackexchange.com/a/" %} -- [Wer nutzt oder möchte PSBTv2 (BIP370) verwenden?](../../en/newsletters/{{bse}}125384) +- [Wer nutzt oder möchte PSBTv2 (BIP370) verwenden?]({{bse}}125384) Neben seinem Posting in der Bitcoin-Dev-Mailingliste (siehe [Newsletter #338][news338 psbtv2]) hat Sjors Provoost auch im Bitcoin Stack Exchange nach Nutzern und potenziellen Anwendern von [PSBTv2][topic psbt] gesucht. Leser von Optech, die an [BIP370][] interessiert sind, werden gebeten, auf die Frage oder den entsprechenden Mailinglisten-Beitrag zu antworten. -- [Im Bitcoin-Genesisblock, welche Teile können beliebig belegt werden?](../../en/newsletters/{{bse}}125274) +- [Im Bitcoin-Genesisblock, welche Teile können beliebig belegt werden?]({{bse}}125274) Pieter Wuille weist darauf hin, dass keines der Felder des [Genesis-Blocks][mempool genesis block] den üblichen Blockvalidierungsregeln unterliegt. Er erklärt: "Buchstäblich alle könnten jeglichen Inhalt enthalten haben. Dort, wo es möglich war, wurde es wie ein normaler Block gestaltet – es hätte aber auch anders sein können." -- [Erkennung von Lightning-Force-Close](../../en/newsletters/{{bse}}122504) +- [Erkennung von Lightning-Force-Close]({{bse}}122504) Sanket1729 und Antoine Poinsot diskutieren, wie der [Block-Explorer][topic block explorers] von mempool.space die Felder [`nLockTime`][topic timelocks] und `nSequence` verwendet, um festzustellen, ob eine Transaktion eine Lightning force close Transaktion ist. -- [Ist eine segwit-formatierte Transaktion mit allen Eingaben vom Typ „Nicht-Witness-Programm" gültig?](../../en/newsletters/{{bse}}125240) +- [Ist eine segwit-formatierte Transaktion mit allen Eingaben vom Typ „Nicht-Witness-Programm" gültig?]({{bse}}125240) Pieter Wuille unterscheidet zwischen [BIP141][], das die Struktur und Gültigkeit im Zusammenhang mit den Segwit-Konsensänderungen und der Berechnung von wtxids bestimmt, und [BIP144][], welches das Serialisierungsformat für die Übertragung von Segwit-Transaktionen definiert. -- [P2TR-Sicherheitsfrage](../../en/newsletters/{{bse}}125334) +- [P2TR-Sicherheitsfrage]({{bse}}125334) Pieter Wuille zitiert aus [BIP341][], das [Taproot][topic taproot] spezifiziert, um zu erklären, warum ein öffentlicher Schlüssel direkt in einer Ausgabe enthalten ist, und geht auf damit verbundene Überlegungen zum Thema Quantencomputing ein. -- [Was genau wird heute unternommen, um Bitcoin quantensicher zu machen?](../../en/newsletters/{{bse}}125171) +- [Was genau wird heute unternommen, um Bitcoin quantensicher zu machen?]({{bse}}125171) Murch kommentiert den aktuellen Stand der quantentechnologischen Fähigkeiten, kürzlich eingeführte [post-quantum Signaturschemata][topic quantum resistance] und den vorgeschlagenen [QuBit – Pay to Quantum Resistant Hash][BIPs #1670]-BIP. -- [Welche schädlichen Auswirkungen hat eine kürzere Inter-Block-Zeit?](../../en/newsletters/{{bse}}125318) +- [Welche schädlichen Auswirkungen hat eine kürzere Inter-Block-Zeit?]({{bse}}125318) Pieter Wuille hebt den Vorteil hervor, den ein Miner aufgrund der Blockpropagation erlangt, kurz nachdem er einen Block gefunden hat, wie dieser Vorteil bei kürzeren Blockzeiten verstärkt wird und welche potenziellen Auswirkungen daraus resultieren können. -- [Kann Proof-of-Work eingesetzt werden, um Richtlinienregeln zu ersetzen?](../../en/newsletters/{{bse}}124931) +- [Kann Proof-of-Work eingesetzt werden, um Richtlinienregeln zu ersetzen?]({{bse}}124931) Jgmontoya fragt sich, ob das Anhängen von Proof-of-Work an nicht-standardmäßige Transaktionen ähnliche Ziele des [Schutzes von Node-Ressourcen][policy series] erreichen könnte wie die Mempool-Policy. Antoine Poinsot weist darauf hin, dass die Mempool-Policy neben dem Schutz der @@ -166,17 +166,17 @@ bestbewerteten Fragen und Antworten hervor, die seit unserem letzten Update gepo Blocktemplates, das Abschrecken bestimmter Transaktionstypen und den Schutz von Upgrade-Hooks bei [Soft Forks][topic soft fork activation]. -- [Wie funktioniert MuSig in realen Bitcoin-Szenarien?](../../en/newsletters/{{bse}}125030) +- [Wie funktioniert MuSig in realen Bitcoin-Szenarien?]({{bse}}125030) Pieter Wuille erläutert die Unterschiede zwischen den [MuSig][topic musig]-Versionen, hebt die Interactive Aggregated Signature (IAS)-Variante von MuSig1 und deren Zusammenspiel mit der [Cross-Input-Signaturaggregation (CISA)][topic cisa] hervor und erwähnt [Threshold Signatures][topic threshold signature], bevor er detailliertere Fragen zu den Spezifikationen beantwortet. -- [Wie funktioniert der -blocksxor-Schalter, der die blocks.dat-Dateien verschleiert?](../../en/newsletters/{{bse}}125055) +- [Wie funktioniert der -blocksxor-Schalter, der die blocks.dat-Dateien verschleiert?]({{bse}}125055) Vojtěch Strnad beschreibt die `-blocksxor`-Option zum Verschleiern der Bitcoin Core Blockdaten-Dateien auf der Festplatte (siehe [Newsletter #316][news316 xor]). -- [Wie funktioniert der Related-Key-Angriff auf Schnorr-Signaturen?](../../en/newsletters/{{bse}}125328) +- [Wie funktioniert der Related-Key-Angriff auf Schnorr-Signaturen?]({{bse}}125328) Pieter Wuille erklärt, dass „der Angriff anwendbar ist, wenn das Opfer einen verwandten Schlüssel auswählt und der Angreifer die Beziehung kennt" und dass verwandte Schlüssel äußerst verbreitet sind. From 4d45297f20449000f8b75e9f097167f19949b35a Mon Sep 17 00:00:00 2001 From: Murch Date: Mon, 3 Feb 2025 16:39:44 -0500 Subject: [PATCH 6/6] [DE] News339: use bemerkt instead of erkannt --- _posts/de/newsletters/2025-01-31-newsletter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/de/newsletters/2025-01-31-newsletter.md b/_posts/de/newsletters/2025-01-31-newsletter.md index 92beeb38af..ffdca48929 100644 --- a/_posts/de/newsletters/2025-01-31-newsletter.md +++ b/_posts/de/newsletters/2025-01-31-newsletter.md @@ -85,7 +85,7 @@ Bitcoin-Infrastruktursoftware beschrieben werden. 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][miningpool.observer] entwickeln und einsetzen, erkannt wird. + [Block-Monitoring-Tools][miningpool.observer] entwickeln und einsetzen, bemerkt wird. - **Aktualisierte Statistiken zur Kompaktblock-Rekonstruktion:** Auf einen vorherigen Thread (siehe [Newsletter #315][news315 cb]) folgend, hat Entwickler 0xB10C