Der Newsletter dieser Woche kündigt ein neues Aggregat-Signaturprotokoll an, das mit secp256k1 kompatibel ist, und beschreibt ein standardisiertes Backup-Schema für Wallet-Deskriptoren. Ebenfalls enthalten sind unsere regulären Abschnitte mit Zusammenfassungen aktueller Fragen und Antworten von Bitcoin Stack Exchange, Ankündigungen neuer Releases und Release-Kandidaten sowie Beschreibungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur.

Nachrichten

  • ● Interaktive Aggregat-Signaturen kompatibel mit secp256k1: Jonas Nick, Tim Ruffing und Yannick Seurin veröffentlichten in der Bitcoin-Dev-Mailingliste einen Hinweis auf ein Paper, das sie über die Erstellung von 64-Byte-Aggregat-Signaturen geschrieben haben, die mit den bereits in Bitcoin verwendeten kryptographischen Primitiven kompatibel sind. Aggregat-Signaturen sind die kryptographische Voraussetzung für Cross-Input Signature Aggregation (CISA), ein vorgeschlagenes Feature für Bitcoin, das die Größe von Transaktionen mit mehreren Inputs reduzieren könnte. Dadurch würden die Kosten vieler verschiedener Arten von Ausgaben sinken – einschließlich datenschutzfreundlicher Ausgaben durch Coinjoins und Payjoins.

    Zusätzlich zu einem Aggregat-Signaturschema, wie dem von den Autoren vorgeschlagenen DahLIAS-Schema, würde die Unterstützung von CISA in Bitcoin eine Konsensänderung erfordern. Mögliche Wechselwirkungen zwischen Signaturaggregation und anderen vorgeschlagenen Konsensänderungen könnten weitere Untersuchungen erfordern.

  • ● Standardisiertes Backup für Wallet-Deskriptoren: Salvatore Ingala veröffentlichte auf Delving Bitcoin eine Zusammenfassung verschiedener Abwägungen beim Backup von Wallet-Deskriptoren und ein vorgeschlagenes Schema, das für viele verschiedene Wallet-Typen nützlich sein sollte, einschließlich solcher mit komplexen Skripten. Sein Schema verschlüsselt Deskriptoren mit einem deterministisch generierten 32-Byte-Geheimnis. Für jeden öffentlichen Schlüssel (oder Extended Public Key) im Deskriptor wird eine Kopie des Geheimnisses mit einer Variante des öffentlichen Schlüssels XOR-verknüpft, wodurch n 32-Byte-Geheimnisverschlüsselungen für n öffentliche Schlüssel entstehen. Jeder, der einen der im Deskriptor verwendeten öffentlichen Schlüssel kennt, kann diesen mit der 32-Byte-Geheimnisverschlüsselung XORen, um das 32-Byte-Geheimnis zu erhalten, das den Deskriptor entschlüsseln kann. Dieses einfache und effiziente Schema ermöglicht es, viele verschlüsselte Kopien eines Deskriptors auf verschiedenen Medien und an verschiedenen Orten zu speichern und dann mit dem BIP32-Wallet-Seed den eigenen xpub zu generieren, mit dem sich der Deskriptor im Notfall wiederherstellen lässt.

Ausgewählte Q&A von Bitcoin Stack Exchange

Bitcoin Stack Exchange ist einer der ersten Orte, an denen Optech-Mitwirkende nach Antworten suchen – oder wenn wir ein paar Minuten Zeit 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.

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 #31247 fügt Unterstützung für das Serialisieren und Parsen von MuSig2-PSBT-Feldern gemäß BIP373 hinzu, damit Wallets MuSig2-Inputs signieren und ausgeben können. Auf der Input-Seite besteht diese aus einem Feld mit den Teilnehmer-Pubkeys, einem separaten Public-Nonce-Feld und einem separaten Partial-Signature-Feld für jeden Signer. Auf der Output-Seite ist es ein einzelnes Feld mit den Teilnehmer-Pubkeys für das neue UTXO.

  • ● LDK #3601 fügt ein neues LocalHTLCFailureReason-Enum hinzu, das jeden Standard-BOLT4-Fehlercode abbildet, zusammen mit einigen Varianten, die dem Nutzer zusätzliche Informationen liefern, die zuvor aus Datenschutzgründen entfernt wurden.