Der Newsletter dieser Woche fasst einen BIP-Entwurf zum Austausch von Block-Templates zwischen Full Nodes zusammen und stellt eine Bibliothek vor, die eine vertrauenswürdige Delegation der Skriptauswertung ermöglicht (auch für Funktionen, die in Bitcoins nativen Skriptsprachen nicht verfügbar sind). Außerdem enthalten sind unsere regelmäßigen Abschnitte mit aktuellen Updates zu Services und Client-Software, Ankündigungen neuer Releases und Release-Kandidaten sowie einer Zusammenfassung Änderungen an wichtiger Bitcoin-Infrastruktur-Software.

Nachrichten

  • ● BIP-Entwurf zum Teilen von Block-Templates: Anthony Towns veröffentlichte in der Bitcoin-Dev-Mailingliste den Entwurf eines BIPs, wie Knoten ihren Peers die Transaktionen mitteilen können, die sie im nächsten Block schürfen würden (Mining) (siehe Newsletter #366). Dadurch kann ein Knoten Transaktionen teilen, die er laut Mempool- und Mining- Policy akzeptiert, die seine Peers aber normalerweise ablehnen würden. Diese Peers können die Transaktionen für den Fall cachen, dass sie gemint werden (was die Effizienz des Compact Block Relay verbessert). Die Transaktionen im Block-Template eines Knotens sind meist die profitabelsten unbestätigten Transaktionen, sodass Peers, die sie zuvor aus Policy-Gründen abgelehnt haben, sie erneut bewerten können.

    Das im Entwurf spezifizierte Protokoll ist einfach: kurz nach Verbindungsaufbau sendet der Knoten eine sendtemplate-Nachricht, um die Bereitschaft zum Senden von Block-Templates zu signalisieren. Später kann der Peer mit einer gettemplate-Nachricht ein Template anfordern. Der Knoten antwortet mit einer template-Nachricht, die eine Liste von kurzen Transaktions-IDs im BIP152-Format enthält. Der Peer kann dann gewünschte Transaktionen per sendtransactions- Nachricht anfordern (ebenfalls wie in BIP152). Der Entwurf erlaubt Templates, die bis etwas mehr als doppelt so groß sind wie das aktuelle Blockgewichtslimit.

    In einem Delving-Bitcoin-Thread gab es weitere Diskussionen zur Verbesserung der Bandbreiteneffizienz. Vorgeschlagen wurden: nur die Differenz zum vorherigen Template zu senden (ca. 90% Ersparnis), ein Set-Reconciliation -Protokoll wie minisketch (ermöglicht effizientes Teilen großer Templates) und Golomb-Rice Kodierung ähnlich wie bei Compact Block Filters (ca. 25% Ersparnis).

  • ● Vertrauenswürdige Delegation der Skriptauswertung: Josh Doman stellte in Delving Bitcoin eine Bibliothek vor, die ein Trusted Execution Environment (TEE) nutzt. Dieses signiert einen Taproot-Keypath-Spend nur, wenn die Transaktion ein Skript erfüllt. Das Skript kann Opcodes enthalten, die aktuell in Bitcoin nicht aktiv sind, oder eine ganz andere Skriptsprache (z. B. Simplicity oder bll).

    Empfänger von Geldern müssen dem TEE vertrauen – sowohl dass es zukünftig verfügbar bleibt, als auch dass es nur dann signiert, wenn das Skript erfüllt ist. Dies ermöglicht schnelle Experimente mit neuen Bitcoin-Features mit echtem Wert. Um das Vertrauen ins TEE zu reduzieren, kann ein Backup-Spend-Pfad eingebaut werden, z. B. ein timelocked Pfad, der nach einem Jahr eine einseitige Ausgabe erlaubt.

    Die Bibliothek ist für die Nutzung mit Amazon Web Services (AWS) Nitro Enclave konzipiert.

Änderungen bei Services und Client-Software

In dieser monatlichen Rubrik stellen wir interessante Updates zu Bitcoin- Wallets und Services vor.

  • ● ZEUS v0.11.3 veröffentlicht: Das v0.11.3 Release bringt Verbesserungen beim Peer-Management, bei BOLT12 und den Submarine Swap-Funktionen.

  • ● Rust-Utreexo-Ressourcen: Abdelhamid Bakhta veröffentlichte Rust-basierte Ressourcen für Utreexo, darunter interaktive Lernmaterialien und WASM-Bindings.

  • ● Peer-Observer-Tooling und Aufruf zur Mitarbeit: 0xB10C stellte Motivation, Architektur, Code, unterstützende Bibliotheken und Erkenntnisse seines Peer-Observer-Projekts vor. Ziel ist eine lose, dezentrale Gruppe von Menschen, die das Bitcoin-Netzwerk überwachen und gemeinsam Ideen, Daten, Tools und Erkenntnisse teilen.

  • ● Bitcoin Core Kernel-basierter Knoten angekündigt: Bitcoin Backbone wurde angekündigt als Demonstration für die Nutzung der Bitcoin Core Kernel-Bibliothek als Basis eines Bitcoin-Nodes.

  • ● SimplicityHL veröffentlicht: SimplicityHL ist eine Rust-ähnliche Programmiersprache, die in die Low-Level-Simplicity-Sprache kürzlich aktiviert auf Liquid kompiliert. Weitere Infos im Delving-Thread.

  • ● LSP-Plugin für BTCPay Server: Das LSP-Plugin implementiert Client-Funktionen von BLIP51, der Spezifikation für eingehende Kanäle, in BTCPay Server.

  • ● Proto Mining-Hardware und -Software angekündigt: Proto stellte neue Bitcoin-Mining-Hardware und Open-Source- Mining-Software vor, entwickelt mit vorherigem Community-Feedback.

  • ● Oracle-Resolution-Demo mit CSFS: Abdelhamid Bakhta zeigte eine Oracle-Demo mit CSFS, nostr und MutinyNet zur Signierung einer Ereignisbestätigung.

  • ● Relai unterstützt Taproot: Relai hat die Unterstützung für das Senden an Taproot-Adressen hinzugefügt.

Releases und Release-Kandidaten

Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie, auf neue Versionen zu aktualisieren oder bei der Testung von Release-Kandidaten zu helfen.

  • ● LND v0.19.3-beta ist ein Release für eine Wartungsversion dieser beliebten LN-Knoten-Implementierung, das “wichtige Bugfixes” enthält. Besonders erwähnenswert ist “eine optionale Migration […], die Festplatten- und Speicheranforderungen für Knoten erheblich senkt.”

  • ● Bitcoin Core 29.1rc1 ist ein Release-Kandidat für eine Wartungsversion der führenden Full-Node-Software.

  • ● Core Lightning v25.09rc2 ist ein Release-Kandidat für eine neue Hauptversion dieser beliebten LN-Knoten-Implementierung.

Wichtige Code- und Dokumentationsänderungen

Wichtige aktuelle Änderungen in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, BIPs, BOLTs, BLIPs, Bitcoin Inquisition und BINANAs.

  • ● Bitcoin Core #32896 ermöglicht das Erstellen und Ausgeben unbestätigter Topologically Restricted Until Confirmation (TRUC)-Transaktionen durch Hinzufügen eines version-Parameters zu den folgenden RPCs: createrawtransaction, createpsbt, send, sendall und walletcreatefundedpsbt. Die Wallet erzwingt die TRUC-Beschränkungen für Gewichtslimit, Konflikte mit Geschwister-Transaktionen und die Unvereinbarkeit zwischen unbestätigten TRUC- und Nicht-TRUC-Transaktionen.

  • ● Bitcoin Core #33106 senkt die Standardwerte für blockmintxfee auf 1 sat/kvB (Minimum) sowie für minrelaytxfee und incrementalrelayfee auf 100 sat/kvB (0,1 sat/vB). Diese Werte sind konfigurierbar, Nutzer sollten minrelaytxfee und incrementalrelayfee gemeinsam anpassen. Andere Mindest-Feerates bleiben unverändert, aber die Standardwerte für Wallet-Feerates werden voraussichtlich in einer zukünftigen Version gesenkt. Gründe für die Änderung sind das starke Wachstum von Blöcken mit Transaktionen unter 1 sat/vB, die Anzahl der Pools, die solche Transaktionen minen, und der gestiegene Bitcoin-Kurs.

  • ● Core Lightning #8467 erweitert xpay (siehe Newsletter #330) um die Unterstützung für Zahlungen an BIP353 Human Readable Names (HRN) (z. B. satoshi@bitcoin.com) und ermöglicht direkte Zahlungen an BOLT12 offers, ohne vorher den Befehl fetchinvoice ausführen zu müssen. Intern holt sich xpay die Zahlungsanweisungen über den RPC-Befehl fetchbip353 aus dem cln-bip353-Plugin, das in Core Lightning #8362 eingeführt wurde.

  • ● Core Lightning #8354 beginnt mit der Veröffentlichung von pay_part_start- und pay_part_end-Event-Benachrichtigungen zum Status einzelner Zahlungsteile, die mit MPP gesendet wurden. Die pay_part_end-Benachrichtigung zeigt die Dauer der Zahlung und ob sie erfolgreich war oder fehlgeschlagen ist. Bei Fehlschlag wird eine Fehlermeldung und, falls der Error-Onion nicht beschädigt ist, zusätzliche Information zur Ursache und zum Fehlercode bereitgestellt.

  • ● Eclair #3103 führt Unterstützung für Simple Taproot Channels ein und nutzt MuSig2 scriptless Multisignature-Signaturen, um das Transaktionsgewicht um 15% zu reduzieren und die Privatsphäre zu verbessern. Funding-Transaktionen und kooperative Schließungen sind von anderen P2TR-Transaktionen nicht zu unterscheiden. Dieser PR enthält auch Unterstützung für Dual Funding und Splicing in Simple Taproot Channels und ermöglicht Channel Commitment Upgrades auf das neue Taproot-Format während einer Splice-Transaktion.

  • ● Eclair #3134 ersetzt den Strafgewicht-Multiplikator für hängende HTLCs durch das CLTV expiry delta bei der Bewertung der HTLC endorsement-Peer-Reputation (siehe Newsletter #363), um besser abzubilden, wie lange ein hängender HTLC Liquidität bindet. Um die übermäßige Strafe für HTLCs mit maximalem CLTV expiry delta zu mildern, werden die Reputation-Decay-Parameter (half-life) von 15 auf 30 Tage und der Schwellenwert für hängende Zahlungen (max-relay-duration) von 12 Sekunden auf 5 Minuten angepasst.

  • ● LDK #3897 erweitert die Peer Storage-Implementierung, indem verlorener Channel-State beim Wiederherstellen von Backups erkannt wird: Die Kopie des Peers wird deserialisiert und mit dem lokalen Zustand verglichen.