Der Newsletter dieser Woche verweist auf Vergleiche verschiedener Cluster-Linearisierungstechniken und fasst kurz die Diskussion über die Erhöhung oder Abschaffung des OP_RETURN-Größenlimits in Bitcoin Core zusammen. Ebenfalls enthalten sind unsere regulären Abschnitte mit Ankündigungen neuer Releases und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur.

Nachrichten

• ● Vergleich von Cluster-Linearisierungstechniken: Pieter Wuille veröffentlichte auf Delving Bitcoin einige grundlegende Abwägungen zwischen drei verschiedenen Cluster-Linearisierungstechniken und ergänzte dies durch Benchmarks 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 brachte weitere Argumente. Anstatt die gesamte umfangreiche Diskussion zusammenzufassen, stellen wir das aus unserer Sicht überzeugendste Argument für und gegen die Änderung vor.

  • ● Für die Erhöhung (oder Abschaffung) des Limits: Pieter Wuille argumentierte, dass die Standardness-Policy von Transaktionen kaum verhindern kann, dass gut finanzierte Organisationen datentragende Transaktionen direkt an Miner senden und so in Blöcke bringen. Außerdem seien Blöcke ohnehin meist voll, egal ob sie Daten enthalten oder nicht, sodass sich die Gesamtmenge der zu speichernden Daten für einen Knoten kaum ändert.

  • ● Gegen die Erhöhung des Limits: Jason Hughes argumentierte, dass eine Erhöhung des Limits es einfacher machen würde, beliebige Daten auf Rechnern zu speichern, die Full Nodes 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), könnte das Speichern und Abrufen solcher Daten über Bitcoin Core RPCs für viele Nutzer problematisch sein.

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.

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 #31250 deaktiviert die Erstellung und das Laden von Legacy-Wallets und schließt damit die Migration zu Deskriptor-Wallets ab, die seit Oktober 2021 Standard sind (siehe Newsletter #172). 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).

• ● 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-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 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.