Der Newsletter dieser Woche beschreibt einen Vorschlag, der es dem Lightning Network ermöglichen soll, Vorab- und Haltegebühren auf Basis von verbrennbaren Outputs zu unterstützen. Zudem fasst er die Diskussionen zu Testnetzen 3 und 4 (inklusive eines Hard-Fork-Vorschlags) zusammen und kündigt einen Plan an, bestimmte Transaktionen mit Taproot-Anhängen weiterzuleiten. Außerdem enthält der Newsletter unsere üblichen Rubriken, in denen ausgewählte Fragen und Antworten vom Bitcoin Stack Exchange, neue Releases und Release-Kandidaten sowie wesentliche Änderungen populärer Bitcoin-Infrastrukturprojekte vorgestellt werden.

News

• ● LN-Vorab- und Haltegebühren mittels verbrennbarer Outputs: John Law hat im Delving Bitcoin-Forum einen Beitrag veröffentlicht, in dem er ein Papier zusammenfasst, das ein Protokoll beschreibt, mit dem Nodes zwei zusätzliche Gebührenarten für das Weiterleiten von Zahlungen erheben können. Eine Vorabgebühr würde vom Endzahler entrichtet, um Weiterleitungsnodes für die temporäre Nutzung eines HTLC-Slots (eine der begrenzten, gleichzeitig verfügbaren Ressourcen in einem Kanal zur Durchsetzung von HTLCs) zu entschädigen. Eine Haltegebühr würde von einem Node gezahlt, der die Abwicklung eines HTLC verzögert; die Höhe dieser Gebühr würde mit der Dauer der Verzögerung ansteigen – bis zum Erreichen des maximalen Betrags, der beim Ablauf des HTLC festgelegt wurde. Sein Beitrag und das Papier verweisen auf mehrere frühere Diskussionen zu Vorab- und Haltegebühren, wie sie in den Newslettern #86, #119, #120, #122, #136 und #263 zusammengefasst wurden.

  Das vorgeschlagene Protokoll baut auf den Ideen von Laws Offchain Payment Resolution (OPR)-Protokoll auf (siehe Newsletter #329), bei dem die Kanalmitbesitzer jeweils 100 % der streitigen Gelder (also insgesamt 200 %) einem verbrennbaren Output zuweisen, den jeder von ihnen einseitig zerstören kann. Die streitigen Gelder umfassen in diesem Fall die Vorabgebühr plus die maximalen Haltegebühren. Wenn beide Parteien später zufrieden sind, dass das Protokoll korrekt befolgt wurde, z. B. dass alle Gebühren korrekt gezahlt wurden, entfernen sie den verbrennbaren Output aus zukünftigen Versionen ihrer Offchain-Transaktionen. Wenn eine Partei unzufrieden ist, schließen sie den Kanal und zerstören die verbrennbaren Gelder. Obwohl die unzufriedene Partei in diesem Fall Gelder verliert, tut dies auch die andere Partei, wodurch verhindert wird, dass eine Partei von der Verletzung des Protokolls profitiert.

  Law beschreibt das Protokoll als Lösung für Channel Jamming Angriffe, eine Schwachstelle im Lightning Network, die erstmals vor fast einem Jahrzehnt beschrieben wurde und es einem Angreifer ermöglicht, fast kostenlos zu verhindern, dass andere Nodes einige oder alle ihrer Gelder nutzen können. In einer Antwort wurde darauf hingewiesen, dass die Einführung von Haltegebühren möglicherweise Hold Invoices für das Netzwerk nachhaltiger machen könnte.

• ● Diskussion zu Testnetzen 3 und 4: Sjors Provoost fragte in der Bitcoin-Dev-Mailingliste nach, ob noch jemand Testnet3 verwendet, da Testnet4 nun seit etwa sechs Monaten im Einsatz ist (siehe Newsletter #315). Andres Schildbach antwortete dahingehend, dass er vorhat, Testnet3 in der Testversion seiner beliebten Wallet mindestens noch ein Jahr lang zu nutzen. Olaoluwa Osuntokun bemerkte, dass Testnet3 in letzter Zeit deutlich stabiler ist als Testnet4. Er untermauerte seinen Standpunkt durch Screenshots der Blockbäume beider Testnets, die von der Fork.Observer-Website stammen. Nachfolgend siehst du unseren eigenen Screenshot, der den Zustand von Testnet4 zum Zeitpunkt der Erstellung zeigt:

  

  Nach Osuntokuns Beitrag startete Antoine Poinsot einen separaten Thread, um sich auf die Probleme von Testnet4 zu konzentrieren. Er argumentiert, dass die Probleme von Testnet4 eine Folge der Regel zum Schwierigkeits-Reset sind. Diese Regel, die nur für Testnet gilt, erlaubt es einem Block, mit minimaler Schwierigkeit gültig zu sein, wenn seine Header-Zeit 20 Minuten später als die seines Elternblocks ist. Provoost geht in Detail auf das Problem ein. Poinsot schlägt einen Hard Fork für Testnet4 vor, um die Regel zu entfernen. Mark Erhardt schlägt ein Datum für den Fork vor: 08.01.2026.

• ● Plan zur Weiterleitung bestimmter Taproot-Anhänge: Peter Todd kündigte in der Bitcoin-Dev-Mailingliste an, dass er plant, seinen auf Bitcoin Core basierenden Node, Libre Relay, so zu aktualisieren, dass er Transaktionen mit Taproot-annexes weiterleitet – vorausgesetzt, diese erfüllen bestimmte Regeln:

  • 0x00-Präfix: “Alle nicht-leeren Anhänge beginnen mit dem Byte 0x00, um sie von [zukünftigen] konsensrelevanten Anhängen zu unterscheiden.”

  • Alles oder nichts: “Alle Inputs müssen einen Anhang besitzen. Dies stellt sicher, dass die Verwendung des Anhangs freiwillig erfolgt und verhindert dadurch Transaction Pinning-Angriffe in Mehrparteien-Protokollen.”

  Der Plan basiert auf einem 2023er Pull Request von Joost Jager, der seinerseits auf einer früheren Diskussion beruhte (siehe Newsletter #255). Nach Jagers Worten begrenzte der frühere Pull Request auch “die maximale Größe unstrukturierter Anhangsdaten auf 256 Bytes […] und bot dadurch einen gewissen Schutz vor einer Inflation des Anhangs in Mehrparteien-Transaktionen.” Todds Version sieht diese Regel nicht vor; er ist der Ansicht, dass “die Voraussetzung, den Einsatz des Anhangs freiwillig zu wählen, ausreichend sein sollte.” Falls dies nicht ausreicht, beschreibt er eine zusätzliche Änderung im Relay, die ein Counterparty Pinning verhindern könnte.

Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange

Der Bitcoin Stack Exchange ist eine der ersten Anlaufstellen für Optech-Mitwirkende, wenn es darum geht, Antworten auf technische Fragen zu finden – oder wenn gerade freie Momente vorhanden sind, um neugierigen oder etwas verwirrten Nutzern zu helfen.

• ● Warum ist das Witness Commitment optional? Pieter Wuille und Antoine Poinsot erklären BIP30 “Duplicate transactions”, BIP34 “Block v2, Height in Coinbase” und consensus cleanup -Überlegungen rund um das Block 1,983,702 Problem und wie die verpflichtende Einführung des Witness Commitments das Problem lösen würde.

• ● Können alle konsensgültigen 64-Byte-Transaktionen (von Dritten) manipuliert werden,um ihre Größe zu ändern? Sjors Provoost untersucht Ideen zur Manipulation von 64-Byte-Transaktionen, die konsensungültig wären, wenn der consensus cleanup-Soft Fork aktiviert würde. Vojtěch Strnad argumentiert, dass nicht jede 64-Byte-Transaktion von Dritten manipuliert werden kann, aber es wäre dennoch der Fall, dass der Output einer 64-Byte-Transaktion entweder unsicher (von jedem ausgebbar) oder nachweislich unspendbar (z. B. ein OP_RETURN) wäre.

• ● Wie lange dauert es, bis eine Transaktion im Netzwerk propagiert(verbreitet) wird? Sr_gi weist darauf hin, dass ein einzelner Node keine netzwerkweiten Transaktionspropagationszeiten messen kann und dass mehrere Nodes im gesamten Bitcoin-Netzwerk erforderlich wären, um Propagationszeiten zu messen und zu schätzen. Er verweist auf eine Website, die von der Decentralized Systems and Network Services Research Group am KIT betrieben wird und unter anderem Transaktionspropagationszeiten misst. Diese zeigt, dass “eine Transaktion etwa ~7 Sekunden benötigt, um 50 % des Netzwerks zu erreichen, und etwa ~17 Sekunden, um 90 % zu erreichen”.

• ● Nützlichkeit der langfristigen Gebührenabschätzung Abubakar Sadiq Ismail sucht Feedback von Projekten, Protokollen oder Nutzern, die sich auf langfristige Gebührenabschätzungen verlassen, für seine Arbeit zur Gebührenabschätzung.

• ● Warum werden zwei Anchor Outputs im LN verwendet? Instagibbs bietet historischen Kontext zu den Anchor Outputs, die derzeit im Lightning Network verwendet werden, und weist darauf hin, dass mit Änderungen an den Bitcoin Core Policies in 28.0 ein geplantes Update zu v3 Commitments erfolgt.

• ● Warum gibt es keine BIPs im Bereich 2xx? Michael Folkson weist darauf hin, dass BIP-Nummern 200-299 zu einem bestimmten Zeitpunkt für Lightning-bezogene BIPs reserviert wurden.

• ● Warum verwendet Bech32 nicht das Zeichen “b”? Bordalix antwortet, dass die visuelle Ähnlichkeit zwischen “B” und “8” der Grund dafür war, “B” in den Bech32 und Bech32m-Adressformaten nicht zuzulassen. Er liefert auch zusätzliche Trivia(Wissenswertes) rund um Bech32.

• ● Bech32 Fehlererkennung und -korrektur Referenzimplementierung Pieter Wuille merkt an, dass Bech32 bis zu vier Fehler in der Adresscodierung erkennen und zwei Substitutionsfehler korrigieren kann.

• ● Wie kann man sicher Staub ausgeben/verbrennen? Murch listet Dinge auf, die beim Senden von Staub aus einer bestehenden Wallet zu beachten sind.

• ● Wie wird die Rückerstattungstransaktion in Asymmetric Revocable Commitments konstruiert? Biel Castellarnau geht die Beispiele von Commitment-Transaktionen aus dem Buch Mastering Bitcoin durch.

• ● Welche Anwendungen nutzen ZMQ mit Bitcoin Core? Sjors Provoost sucht Nutzer der ZMQ-Dienste von Bitcoin Core im Rahmen der Untersuchung, ob IPC diese Anwendungen ersetzen könnte.

Releases und Release-Kandidaten

Neuerscheinungen und Release-Kandidaten populärer Bitcoin-Infrastrukturprojekte – bitte erwägen Sie ein Upgrade oder helfen Sie beim Testen neuer Versionen.

• ● Bitcoin Core 29.0rc2 ist ein Release-Kandidat für die nächste Hauptversion des am weitesten verbreiteten Full Nodes. Bitte sehen Sie sich den Version 29 Testing Guide an.

• ● LND 0.19.0-beta.rc1 ist ein Release-Kandidat für diesen beliebten LN-Knoten. Einer der wesentlichen Verbesserungsansätze, der sicherlich weiterer Tests bedarf, ist das neue, auf RBF-basierte Fee-Bumping für kooperative Kanal-Schließungen, das unten im Abschnitt zu den wesentlichen Codeänderungen beschrieben wird.

Wichtige Änderungen an Code und Dokumentation

Bedeutende jüngste Ä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 #31603 aktualisiert den Parser ParsePubkeyInner, um öffentliche Schlüssel mit führenden oder nachgestellten Leerzeichen abzulehnen – entsprechend dem Parsing-Verhalten des rust-miniscript-Projekts. Es sollte zuvor nicht möglich gewesen sein, versehentlich Leerzeichen hinzuzufügen, da der Schutz der Descriptor-Prüfsumme dies verhindert. Die RPC-Befehle getdescriptorinfo und importdescriptors werfen jetzt einen Fehler, wenn das öffentliche Schlüssel-Fragment eines Descriptors solche Leerzeichen enthält.

• ● Eclair #3044 erhöht die standardmäßige Mindestanzahl an Bestätigungen für die Kanalsicherheit gegen Block-Reorganisationen von 6 auf 8. Es entfernt auch die Skalierung dieses Werts basierend auf dem Kanal-Finanzierungsbetrag, da die Kanal-Kapazität während des Splicing erheblich geändert werden kann, was den Node dazu bringen könnte, eine niedrige Anzahl von Bestätigungen für tatsächlich große Geldbeträge zu akzeptieren.

• ● Eclair #3026 fügt Unterstützung für Bitcoin Core Wallets mit Pay-to-Taproot (P2TR)-Adressen hinzu, einschließlich Watch-Only-Wallets, die von Eclair verwaltet werden, als Grundlage für die Implementierung einfacher Taproot-Kanäle. P2WPKH-Skripte sind weiterhin für einige gegenseitige Schließungstransaktionen erforderlich, auch bei Verwendung einer P2TR-Wallet.

• ● LDK #3649 ermöglicht das Bezahlen von Lightning Service Providern (LSPs) mit BOLT12 offers durch zusätzliche Felder. Zuvor waren nur BOLT11 und On-Chain-Zahlungsoptionen aktiviert. Dies wurde auch in BLIPs #59 vorgeschlagen.

• ● LDK #3665 vergrößert das Limit für BOLT11-Invoices von 1.023 auf 7.089 Bytes, um LNDs Limit anzupassen, das auf der maximalen Anzahl von Bytes basiert, die auf einen QR-Code passen. Der PR-Autor argumentiert, dass QR-Codes, die mit der Codierung in einer BOLT11-Rechnung kompatibel sind, tatsächlich auf 4.296 Zeichen begrenzt sind, aber der Wert von 7.089 wird für LDK gewählt, da “systemweite Konsistenz wahrscheinlich wichtiger ist.”

• ● LND #8453, #9559, #9575, #9568, und LND #9610 führen einen RBF kooperativen Close-Flow basierend auf BOLTs #1205 (siehe Newsletter #342) ein, der es beiden Peers ermöglicht, durch eigene Kanal-Fonds die Gebühr zu erhöhen. Zuvor mussten Peers manchmal ihre Gegenpartei überzeugen, für Gebührenanhebungen zu zahlen, was oft zu gescheiterten Versuchen führte. Um diese Funktion zu aktivieren, muss die Konfigurationsflagge protocol.rbf-coop-close gesetzt werden.

• ● BIPs #1792 aktualisiert BIP119, das OP_CHECKTEMPLATEVERIFY spezifiziert, durch eine überarbeitete Formulierung, die Sprache für bessere Klarheit überarbeitet, die Aktivierungslogik entfernt, Eltoo in LN-Symmetry umbenennt und Erwähnungen neuer Covenant-Vorschläge und Projekte wie Ark hinzufügt, die OP_CTV verwenden.

• ● BIPs #1782 reformatiert den Spezifikationsabschnitt von BIP94, der die Konsensregeln von Testnet4 klarer und leserlicher darstellt.