DE-352: Remove timestamps

Author: murchandamus

_posts/de/newsletters/2025-05-02-newsletter.md

@@ -12,7 +12,7 @@ Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linear
 ## Nachrichten
 
 - **Vergleich von Cluster-Linearisationstechniken:**
-  Pieter Wuille [veröffentlichte][wuille clustrade] auf Delving Bitcoin einige grundlegende Abwägungen zwischen drei verschiedenen Cluster-Linearisationstechniken und ergänzte dies durch [Benchmarks][wuille clusbench] der jeweiligen Implementierungen. Mehrere andere Entwickler diskutierten die Ergebnisse und stellten Rückfragen, auf die Wuille antwortete. {% assign timestamp="0:41" %}
+  Pieter Wuille [veröffentlichte][wuille clustrade] auf Delving Bitcoin einige grundlegende Abwägungen zwischen drei verschiedenen Cluster-Linearisationstechniken und ergänzte dies durch [Benchmarks][wuille clusbench] der jeweiligen Implementierungen. Mehrere andere Entwickler diskutierten die Ergebnisse und stellten Rückfragen, auf die Wuille antwortete.
 
 - **Erhöhung oder Abschaffung des `OP_RETURN`-Größenlimits in Bitcoin Core:**
   In einem Thread auf der Bitcoin-Dev-Mailingliste diskutierten mehrere Entwickler, das Standardlimit für `OP_RETURN`-Data-Carrier-Outputs in Bitcoin Core zu ändern oder ganz abzuschaffen. Eine nachfolgende [Pull-Request-Diskussion][bitcoin core #32359] brachte weitere Argumente. Anstatt die gesamte umfangreiche Diskussion zusammenzufassen, stellen wir das aus unserer Sicht überzeugendste Argument für und gegen die Änderung vor.
@@ -23,27 +23,25 @@ Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linear
   - *Gegen die Erhöhung des Limits:*
     Jason Hughes [argumentierte][hughes opr], dass eine Erhöhung des Limits es einfacher machen würde, beliebige Daten auf Rechnern zu speichern, die Full Knoten betreiben – darunter auch potenziell anstößige oder in vielen Ländern illegale Inhalte. Selbst wenn der Knoten die Daten auf der Festplatte verschlüsselt (siehe [Newsletter #316][news316 blockxor]), könnte das Speichern und Abrufen solcher Daten über Bitcoin Core RPCs für viele Nutzer problematisch sein.
 
-{% assign timestamp="6:46" %}
 
 ## 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._
 
-- [LND 0.19.0-beta.rc3][] ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollten, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen. {% assign timestamp="1:01:16" %}
+- [LND 0.19.0-beta.rc3][] ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollten, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen.
 
 ## Wichtige Code- und Dokumentationsänderungen
 
 _Bedeutende kürzliche Ä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 #31250][] deaktiviert die Erstellung und das Laden von Legacy-Wallets und schließt damit die Migration zu [Deskriptor][topic descriptors]-Wallets ab, die seit Oktober 2021 Standard sind (siehe Newsletter [#172][news172 descriptors]). Berkeley DB-Dateien von Legacy-Wallets können nicht mehr geladen werden, und alle Unit- und Funktionstests für Legacy-Wallets werden entfernt. Ein Teil des Legacy-Wallet-Codes bleibt noch erhalten, wird aber in Folge-PRs entfernt. Bitcoin Core kann weiterhin Legacy-Wallets in das neue Deskriptor-Wallet-Format migrieren (siehe [Newsletter #305][news305 bdbro]). {% assign timestamp="1:02:10" %}
+- [Bitcoin Core #31250][] deaktiviert die Erstellung und das Laden von Legacy-Wallets und schließt damit die Migration zu [Deskriptor][topic descriptors]-Wallets ab, die seit Oktober 2021 Standard sind (siehe Newsletter [#172][news172 descriptors]). Berkeley DB-Dateien von Legacy-Wallets können nicht mehr geladen werden, und alle Unit- und Funktionstests für Legacy-Wallets werden entfernt. Ein Teil des Legacy-Wallet-Codes bleibt noch erhalten, wird aber in Folge-PRs entfernt. Bitcoin Core kann weiterhin Legacy-Wallets in das neue Deskriptor-Wallet-Format migrieren (siehe [Newsletter #305][news305 bdbro]).
 
-- [Eclair #3064][] überarbeitet das Channel-Key-Management durch Einführung einer `ChannelKeys`-Klasse. Jeder Channel hat nun ein eigenes `ChannelKeys`-Objekt, das zusammen mit den Commitment-Points ein `CommitmentKeys`-Set für die Signierung von Remote/Local-Commitment- und [HTLC][topic htlc]-Transaktionen ableitet. Die Logik für Zwangsschließungen und das Erstellen von Script/Witness wird ebenfalls angepasst. Zuvor war die Schlüsselerzeugung auf mehrere Teile des Codes verteilt, was fehleranfällig war, da die richtige Pubkey-Übergabe nicht typgesichert war. {% assign timestamp="1:06:02" %}
+- [Eclair #3064][] überarbeitet das Channel-Key-Management durch Einführung einer `ChannelKeys`-Klasse. Jeder Channel hat nun ein eigenes `ChannelKeys`-Objekt, das zusammen mit den Commitment-Points ein `CommitmentKeys`-Set für die Signierung von Remote/Local-Commitment- und [HTLC][topic htlc]-Transaktionen ableitet. Die Logik für Zwangsschließungen und das Erstellen von Script/Witness wird ebenfalls angepasst. Zuvor war die Schlüsselerzeugung auf mehrere Teile des Codes verteilt, was fehleranfällig war, da die richtige Pubkey-Übergabe nicht typgesichert war.
 
-- [BTCPay Server #6684][] fügt Unterstützung für einen Teil der [BIP388][]-Wallet-Policy-[Deskriptoren][topic descriptors] hinzu, sodass Nutzer sowohl Single-Sig- als auch k-of-n-Policies importieren und exportieren können. Unterstützt werden die von Sparrow verwendeten Formate wie P2PKH, P2WPKH, P2SH-P2WPKH und P2TR sowie die entsprechenden Multisig-Varianten (außer P2TR). Ziel dieses PR ist die Verbesserung der Multisig-Wallet-Nutzung. {% assign timestamp="1:07:46" %}
+- [BTCPay Server #6684][] fügt Unterstützung für einen Teil der [BIP388][]-Wallet-Policy-[Deskriptoren][topic descriptors] hinzu, sodass Nutzer sowohl Single-Sig- als auch k-of-n-Policies importieren und exportieren können. Unterstützt werden die von Sparrow verwendeten Formate wie P2PKH, P2WPKH, P2SH-P2WPKH und P2TR sowie die entsprechenden Multisig-Varianten (außer P2TR). Ziel dieses PR ist die Verbesserung der Multisig-Wallet-Nutzung.
 
-- [BIPs #1555][] merged [BIP321][], das ein URI-Schema für Bitcoin-Zahlungsanweisungen vorschlägt, das [BIP21][] modernisiert und erweitert. Es behält den alten pfadbasierten Adressstil bei, standardisiert aber die Nutzung von Query-Parametern, sodass neue Zahlungsarten über eigene Parameter identifiziert werden können. Das Adressfeld kann leer bleiben, wenn mindestens eine Anweisung als Query-Parameter angegeben ist. Optional kann ein Zahlungsnachweis für den Sender bereitgestellt werden, und es gibt Hinweise zur Integration neuer Zahlungsanweisungen. {% assign timestamp="1:10:34" %}
+- [BIPs #1555][] merged [BIP321][], das ein URI-Schema für Bitcoin-Zahlungsanweisungen vorschlägt, das [BIP21][] modernisiert und erweitert. Es behält den alten pfadbasierten Adressstil bei, standardisiert aber die Nutzung von Query-Parametern, sodass neue Zahlungsarten über eigene Parameter identifiziert werden können. Das Adressfeld kann leer bleiben, wenn mindestens eine Anweisung als Query-Parameter angegeben ist. Optional kann ein Zahlungsnachweis für den Sender bereitgestellt werden, und es gibt Hinweise zur Integration neuer Zahlungsanweisungen.
 
-{% include snippets/recap-ad.md when="2025-05-06 16:30" %}
 {% include references.md %}
 {% include linkers/issues.md v=2 issues="31250,3064,6684,1555,32359" %}
 [lnd 0.19.0-beta.rc3]: https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta.rc3