Der Newsletter dieser Woche enthält ein Update zum differenziellen Fuzzing von Bitcoin- und LN-Implementierungen und verweist auf eine neue Arbeit zu “garbled locks” für nachvollziehbare Computing-Verträge. Außerdem enthalten sind unsere regelmäßigen Abschnitte mit beliebten Fragen und Antworten aus Bitcoin Stack Exchange, Ankündigungen neuer Releases und Release-Kandidaten sowie einer Zusammenfassung bedeutender Änderungen an wichtiger Bitcoin-Infrastruktur-Software.

Nachrichten

• ● Update zum differenziellen Fuzzing von Bitcoin- und LN-Implementierungen: Bruno Garcia berichtete in Delving Bitcoin über aktuelle Fortschritte und Ergebnisse von bitcoinfuzz, einer Bibliothek und zugehörigen Daten für fuzz testing von Bitcoin-basierter Software und Bibliotheken. Zu den Erfolgen zählt die Entdeckung von “über 35 Bugs in Projekten wie btcd, rust-bitcoin, rust-miniscript, Embit, Bitcoin Core, Core Lightning und LND”. Gefundene Unterschiede zwischen LN-Implementierungen haben nicht nur Fehler aufgedeckt, sondern auch zu Klarstellungen in der LN-Spezifikation geführt. Entwickler von Bitcoin-Projekten werden ermutigt, ihre Software als unterstütztes Ziel für bitcoinfuzz zu prüfen.

• ● Garbled Locks für nachvollziehbare Computing-Verträge: Liam Eagen stellte in der Bitcoin-Dev-Mailingliste eine Arbeit zu einem neuen Mechanismus für die Erstellung von nachvollziehbaren Computing-Verträgen vor, der auf garbled circuits basiert. Dies ähnelt (ist aber verschieden von) anderen aktuellen Arbeiten zu Garbled Circuits für BitVM (siehe Newsletter #359). Eagen behauptet, dass sein Ansatz “das erste (seiner Meinung nach) praktische Garbled Lock ist, dessen Betrugsnachweis eine einzelne Signatur ist, was eine über 550-fache Reduktion der Onchain-Daten gegenüber BitVM2 bedeutet.” Zum Zeitpunkt des Schreibens gab es noch keine öffentlichen Antworten auf seinen Post.

Ausgewählte Fragen & Antworten von Bitcoin Stack Exchange

Bitcoin Stack Exchange ist eine der ersten Anlaufstellen für Optech-Mitwirkende, wenn sie Antworten auf ihre Fragen suchen – oder wenn wir ein paar freie Minuten haben, um neugierigen oder ratlosen Nutzern zu helfen. In dieser monatlichen Rubrik heben wir einige der am höchsten bewerteten Fragen und Antworten hervor, die seit unserem letzten Update gepostet wurden.

• ● Ist es möglich, einen privaten Schlüssel aus einem aggregierten öffentlichen Schlüssel unter starken Annahmen wiederherzustellen? Pieter Wuille erläutert aktuelle und hypothetische Sicherheitsannahmen rund um MuSig2 scriptless Multisignaturen.

• ● Sind alle Taproot-Adressen anfällig für Quantencomputing? Hugo Nguyen und Murch weisen darauf hin, dass selbst Taproot-Outputs, die nur über Skriptpfade ausgegeben werden können, gegenüber Quanten verwundbar sind. Murch merkt an: “Interessanterweise könnte die Partei, die das Output-Skript erzeugt hat, zeigen, dass der interne Schlüssel ein NUMS-Punkt war und damit beweisen, dass eine Quantenentschlüsselung stattgefunden hat.”

• ● Warum kann man den Chainstate-Verschlüsselungsschlüssel nicht setzen? Ava Chow hebt hervor, dass der Schlüssel, der die Inhalte des blocksdir auf der Festplatte verschleiert (siehe Newsletter #339), nicht derselbe ist wie der Schlüssel, der die Inhalte von chainstate verschleiert (siehe Bitcoin Core #6650).

• ● Ist es möglich, einen Ausgabepfad nach einer Blockhöhe zu widerrufen? Antoine Poinsot verweist auf eine frühere Antwort, die bestätigt, dass auslaufende Ausgabebedingungen oder “inverse Timelocks” nicht möglich und vielleicht auch nicht wünschenswert sind.

• ● Bitcoin Core so konfigurieren, dass Onion-Nodes zusätzlich zu IPv4- und IPv6-Nodes verwendet werden? Pieter Wuille stellt klar, dass die Einstellung der Option onion nur für ausgehende Peer-Verbindungen gilt. Er beschreibt außerdem, wie Tor und bitcoind für eingehende Verbindungen konfiguriert werden können.

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.

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

• ● Core Lightning v25.09rc4 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 #31802 aktiviert standardmäßig die Interprozesskommunikation (IPC) (ENABLE_IPC) und fügt die Multiprozess-Binaries bitcoin-node und bitcoin-gui zu den Release-Builds auf allen Systemen außer Windows hinzu. Dadurch kann ein externer Stratum v2-Mining-Service, der Block-Templates erstellt, verwaltet und einreicht, mit dem Multiprozess-Layout experimentieren, ohne eigene Builds zu benötigen. Weitere Informationen zum Multiprozess-Projekt und zum bitcoin-node-Binary finden sich in den Newslettern #99, #147, #320 und #323.

• ● LDK #3979 fügt Unterstützung für Splice-Out hinzu und ermöglicht einem LDK-Knoten, sowohl eine Splice-Out-Transaktion zu initiieren als auch Anfragen von Gegenparteien zu akzeptieren. Damit ist die Splicing-Implementierung in LDK abgeschlossen, da LDK #3736 bereits Splice-In-Unterstützung hinzugefügt hat. Der PR führt ein SpliceContribution-Enum ein, das sowohl In- als auch Out-Szenarien abdeckt und sicherstellt, dass die Output-Werte einer Splice-Out-Transaktion nach Abzug von Gebühren und Reserven den Kanal-Saldo nicht überschreiten.

• ● LND #10102 fügt eine Option gossip.ban-threshold hinzu (Standardwert 100, 0 deaktiviert), mit der Nutzer den Schwellenwert konfigurieren können, ab dem ein Peer für das Senden ungültiger Gossip-Nachrichten gebannt wird. Das Peer-Banning-System wurde zuvor eingeführt und in Newsletter #319 behandelt. Der PR behebt außerdem ein Problem, bei dem unnötige Node- und Kanal Announcement-Nachrichten als Antwort auf eine Backlog-Gossip-Abfrage gesendet wurden.

• ● Rust Bitcoin #4907 führt Script-Tagging ein, indem ein generischer Tag-Parameter T zu Script und ScriptBuf hinzugefügt wird. Es werden die Typ-Aliase ScriptPubKey, ScriptSig, RedeemScript, WitnessScript und TapScript definiert, die durch ein versiegeltes Tag-Trait für Kompilierzeit-Rollensicherheit abgesichert sind.