Der Newsletter dieser Woche beschreibt eine behobene Schwachstelle, die ältere Versionen von Bitcoin Core betrifft. Ebenfalls enthalten sind unsere regulären Abschnitte mit Zusammenfassungen aktueller Diskussionen über Änderungen der Bitcoin-Konsensregeln, Ankündigungen neuer Releases und Release-Kandidaten sowie Beschreibungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur.

Nachrichten

  • ● Offenlegung einer Schwachstelle in alten Versionen von Bitcoin Core: Antoine Poinsot berichtete auf der Bitcoin-Dev-Mailingliste über eine Schwachstelle, die Bitcoin Core-Versionen vor 29.0 betrifft. Die Schwachstelle wurde ursprünglich von Eugene Siegel verantwortungsvoll gemeldet, zusammen mit einer weiteren, eng verwandten Schwachstelle, die in Newsletter #314 beschrieben wurde. Ein Angreifer konnte eine übermäßige Anzahl von Knoten-Adressanzeigen senden, um einen 32-Bit-Identifier zum Überlaufen zu bringen, was zu einem Absturz des Knotens führte. Dies wurde teilweise dadurch entschärft, dass die Anzahl der Updates auf eines pro Peer alle zehn Sekunden begrenzt wurde, was bei etwa 125 Peers im Standardfall ein Überlaufen nur dann ermöglicht hätte, wenn der Knoten über mehr als 10 Jahre kontinuierlich angegriffen worden wäre. Die Schwachstelle wurde vollständig behoben, indem ab Version 29.0 von Bitcoin Core 64-Bit-Identifier verwendet werden.

Änderungen am Konsens

Ein monatlicher Abschnitt mit Zusammenfassungen von Vorschlägen und Diskussionen zu Änderungen der Bitcoin-Konsensregeln.

  • ● Vorgeschlagenes BIP für 64-Bit-Arithmetik in Script: Chris Stewart veröffentlichte auf der Bitcoin-Dev-Mailingliste einen BIP-Entwurf, der vorschlägt, die bestehenden Opcodes von Bitcoin so zu erweitern, dass sie mit 64-Bit-Zahlen arbeiten. Dies folgt auf seine frühere Forschung (siehe Newsletter #285, #290 und #306). Im Unterschied zu früheren Diskussionen verwendet der neue Vorschlag Zahlen im gleichen compactSize-Datenformat, das derzeit in Bitcoin genutzt wird. Weitere Diskussionen dazu fanden in zwei Threads auf Delving Bitcoin statt.

  • ● Vorgeschlagene Opcodes für rekursive Covenants mittels Quines: Auf Delving Bitcoin schlug Bram Cohen eine Reihe einfacher Opcodes vor, mit denen sich rekursive Covenants durch selbstreproduzierende Skripte (Quines) erstellen ließen. Cohen beschreibt, wie die Opcodes genutzt werden könnten, um einen einfachen Vault zu bauen, und erwähnt ein fortgeschritteneres System, an dem er arbeitet.

  • ● Beschreibung der Vorteile für BitVM durch OP_CTV und OP_CSFS: Robin Linus beschrieb auf Delving Bitcoin mehrere Verbesserungen für BitVM, die durch die vorgeschlagenen Opcodes OP_CTV und OP_CSFS per Soft Fork möglich würden. Zu den Vorteilen zählen eine höhere Anzahl von Operatoren ohne Nachteile, „etwa 10-fach kleinere Transaktionen“ (was die Worst-Case-Kosten reduziert) und die Möglichkeit nicht-interaktiver Peg-ins für bestimmte Verträge.

Releases und Release-Kandidaten

Neue Releases und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. Bitte erwäge, auf neue Releases zu aktualisieren oder Release-Kandidaten zu testen.

  • ● LND 0.19.0-beta.rc4 ist ein Release-Kandidat für diesen populären LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollte, ist das neue RBF-basierte Fee-Bumping für kooperative Channel-Schließungen.

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, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition und BINANAs.

  • ● Bitcoin Core #32155 aktualisiert den internen Miner, sodass Coinbase-Transaktionen mit Timelocks versehen werden, indem das Feld nLockTime auf die aktuelle Blockhöhe minus eins gesetzt und das Feld nSequence nicht final gesetzt wird (um das Timelock zu erzwingen). Obwohl der eingebaute Miner normalerweise nicht im Mainnet verwendet wird, sollen Mining-Pools durch dieses Update frühzeitig zur Übernahme dieser Änderungen in ihrer eigenen Software motiviert werden – als Vorbereitung auf den vorgeschlagenen Consensus Cleanup Soft Fork (BIP54). Das Timelocking von Coinbase-Transaktionen löst die Duplicate Transaction-Schwachstelle und würde erlauben, die aufwändigen BIP30-Prüfungen zu entfernen.

  • ● Bitcoin Core #28710 entfernt den verbleibenden Legacy-Wallet-Code, die zugehörige Dokumentation und Tests. Dazu gehören die ausschließlich für Legacy-Wallets bestimmten RPCs wie importmulti, sethdseed, addmultisigaddress, importaddress, importpubkey, dumpwallet, importwallet und newkeypool. Als letzter Schritt für die Entfernung der Legacy-Wallets werden auch die BerkeleyDB-Abhängigkeit und zugehörige Funktionen entfernt. Das absolute Minimum an Legacy-Code und ein unabhängiger BDB-Parser (siehe Newsletter #305) bleiben jedoch erhalten, um die Migration zu Descriptor-Wallets zu ermöglichen.

  • ● Core Lightning #8272 deaktiviert das DNS-Seed-Lookup-Fallback für die Peer-Discovery im Verbindungs-Daemon connectd, um Blockierungsprobleme durch Offline-DNS-Seeds zu vermeiden.

  • ● LND #8330 fügt dem bimodalen Wahrscheinlichkeitsmodell für das Pathfinding eine kleine Konstante (1/c) hinzu, um numerische Instabilitäten zu beheben. In Randfällen, in denen die Berechnung sonst aufgrund von Rundungsfehlern fehlschlagen und eine Wahrscheinlichkeit von Null liefern würde, sorgt diese Regularisierung dafür, dass das Modell auf eine Gleichverteilung zurückfällt. Damit werden Normalisierungsfehler behoben, die bei sehr großen Channels oder solchen auftreten, die nicht in eine bimodale Verteilung passen. Außerdem überspringt das Modell jetzt unnötige Wahrscheinlichkeitsberechnungen und korrigiert automatisch veraltete Channel-Liquiditätsbeobachtungen und widersprüchliche historische Informationen.

  • ● Rust Bitcoin #4458 ersetzt die Struktur MtpAndHeight durch ein explizites Paar aus dem neu hinzugefügten BlockMtp und dem bereits existierenden BlockHeight, um Blockhöhe und Median Time Past (MTP) bei relativen Timelocks besser modellieren zu können. Im Gegensatz zu locktime::absolute::MedianTimePast, das auf Werte über 500 Millionen (etwa nach 1985) beschränkt ist, kann BlockMtp jeden 32-Bit-Timestamp darstellen. Das macht ihn geeignet für theoretische Spezialfälle, wie Chains mit ungewöhnlichen Zeitstempeln. Das Update führt außerdem BlockMtpInterval ein und benennt BlockInterval in BlockHeightInterval um.

  • ● BIPs #1848 aktualisiert den Status von BIP345 auf „Withdrawn“, da der Autor glaubt, dass der vorgeschlagene Opcode OP_VAULT durch OP_CHECKCONTRACTVERIFY (OP_CCV), ein allgemeineres Vault-Design und eine neue Art von Covenant verdrängt wurde.

  • ● BIPs #1841 merged BIP172, das vorschlägt, die unteilbare Basiseinheit von Bitcoin als „Satoshi“ formell zu definieren, um die aktuelle, weit verbreitete Nutzung widerzuspiegeln und die Terminologie in Anwendungen und Dokumentation zu standardisieren.

  • ● BIPs #1821 merged BIP177, das vorschlägt, „Bitcoin“ als die kleinste unteilbare Einheit (üblicherweise als 1 Satoshi bezeichnet) und nicht mehr als 100.000.000 Einheiten zu definieren. Das Ziel ist, die Terminologie an die tatsächliche Basiseinheit anzupassen und Verwirrung durch willkürliche Dezimal-Konventionen zu vermeiden.