Der Newsletter dieser Woche kündigt einen BIP-Entwurf für die Referenzierung nicht ausgabefähiger Schlüssel in Deskriptoren an, untersucht, wie Implementierungen PSBTv2 verwenden, und nimmt ausführliche Korrekturen an unserer Beschreibung eines neuen Off-Chain-DLC-Protokolls von der letzten Woche vor. Darüber hinaus enthalten sind unsere regulären Abschnitte, in denen Änderungen an Diensten und Client-Software beschrieben, neue Versionen und Release-Kandidaten angekündigt und aktuelle Änderungen an beliebter Bitcoin-Infrastruktursoftware zusammengefasst werden.

News

  • ● BIP-Entwurf für nicht ausgabefähige Schlüssel in Deskriptoren: Andrew Toth hat auf der Delving Bitcoin und der Bitcoin-Dev Mailingliste einen BIP-Entwurf veröffentlicht, der die Referenzierung von nachweislich nicht ausgabefähigen Schlüsseln in Deskriptoren behandelt. Diese Veröffentlichung baut auf einer früheren Diskussion auf, die in unserem Newsletter #283 näher ausgeführt ist. Die Verwendung eines nachweislich nicht ausgabefähigen Schlüssels, auch als “nothing up my sleeve” (NUMS)-Punkt bezeichnet, ist besonders relevant für den internen Taproot-Schlüssel. Sofern die Erstellung eines Keypath Spend mit dem internen Schlüssel nicht möglich ist, kann alternativ ein Scriptpath Spend mit einem Tapleaf erstellt werden (beispielsweise mit einem Tapscript).

    Zum Zeitpunkt der Erstellung dieses Dokuments findet eine aktive Diskussion über die PR für den Entwurf des BIP statt.

  • ● PSBTv2 Integrationstests: Sjors Provoost hat in der Bitcoin-Dev-Mailingliste nach Software gesucht, die Unterstützung für PSBTs der Version 2 implementiert hat (siehe Newsletter #141). Ziel ist es, beim Testen eines PR zu helfen, der Bitcoin Core-Unterstützung dafür hinzufügt. Auf dem Bitcoin Stack Exchange findet sich eine aktualisierte Liste der von ihm verwendeten Software. Zwei Antworten waren von Interesse:

    • ● Merklized PSBTv2: Salvatore Ingala erläutert, dass die Ledger Bitcoin App die Felder eines PSBTv2 in einen Merkle-Baum umwandelt und zunächst nur die Wurzel an ein Ledger-Hardware-Signaturgerät sendet. Bei Bedarf werden spezifische Felder zusammen mit dem entsprechenden Merkle-Proof gesendet. Diese Vorgehensweise erlaubt es dem Gerät, mit jedem Informationselement isoliert zu arbeiten, ohne dass eine Speicherung der gesamten PSBT im begrenzten Speicher erforderlich ist. Diese Funktionalität wird durch das PSBTv2-Format ermöglicht, da die Bestandteile der nicht signierten Transaktion bereits in separate Felder unterteilt sind. Im ursprünglichen PSBT-Format (v0) war eine zusätzliche Analyse notwendig.

    • ● Silent payments PSBTv2: BIP352 spezifiziert, dass Silent Payments ausdrücklich von der BIP370-Spezifikation von PSBTv2 abhängig ist. Andrew Toth erklärt, dass Silent Payments das PSBT_OUT_SCRIPT-Feld der Version 2 benötigen, da das zu verwendende Ausgabescript für Silent Payments erst bekannt sein kann, nachdem alle Unterzeichner das PSBT bearbeitet haben.

  • ● Korrektur zu Off-Chain-DLCs: In der jüngsten Ausgabe unseres Newsletters wurde eine Verwechslung zwischen dem von dem Entwickler Conduition vorgeschlagenen neuen Schema für Off-Chain-DLCs und zuvor veröffentlichten und implementierten Off-Chain-DLC-Schemen festgestellt. Diese Verwechslung resultiert in einem signifikanten und interessanten Unterschied, der in der folgenden Analyse erörtert wird:

    • ● Bezüglich des in den Newsletter#174 und Newsletter#260 erwähnten DLC channels Protokoll verwendet einen Mechanismus, der mit dem LN-Penalty-Commit-and-Revoke vergleichbar ist. Bei diesem Mechanismus kommt es zur Interaktion der Parteien, die durch commit auf einen neuen Status festgelegt werden und durch revoke den alten Status, indem sie ein Geheimnis freigeben. Dieses ermöglicht es der Gegenpartei, ihre private Version des alten Status vollständig auszugeben, falls dieser auf der Blockchain veröffentlicht wird. Dadurch kann ein DLC durch Interaktion zwischen den Parteien erneuert werden. Alice und Bob machen beispielsweise Folgendes:

      1. Die Beteiligten einigen sich unverzüglich auf einen DLC für den BTCUSD-Preis, der einen Monat von jetzt an gültig ist.

      2. Drei Wochen später einigen sie sich auf einen DLC für den BTCUSD-Preis, der zwei Monate von jetzt an gültig ist, und widerrufen das vorherige DLC.

    • Das neue DLC factories-Protokoll widerruft automatisch die Fähigkeit beider Parteien, Zustände onchain zu veröffentlichen, sobald der Vertrag ausläuft. Dies geschieht, indem jede Orakel-Bestätigung für den Vertrag als das Geheimnis dient, das es der Gegenpartei ermöglicht, einen privaten Zustand vollständig auszugeben, falls dieser onchain veröffentlicht wird. Dadurch werden alte Zustände automatisch aufgehoben, wodurch aufeinanderfolgende DLCs zu Beginn des Produktionssystems ohne weitere Interaktionen unterzeichnet werden können. Zum Beispiel führen Alice und Bob folgende Schritte aus:

      1. Sie einigen sich sofort auf einen DLC für den BTCUSD-Preis, der einen Monat von jetzt an gültig ist.

      2. Sie einigen sich ebenfalls sofort auf einen DLC für den BTCUSD-Preis, der zwei Monate von jetzt an gültig ist, mit einer timelock, die dessen Veröffentlichung erst einen Monat von jetzt an ermöglicht. Sie können dies für den dritten, vierten Monat usw. wiederholen.

    Im DLC-Channels-Protokoll können Alice und Bob den zweiten Vertrag nicht erstellen, bevor sie bereit sind, den ersten Vertrag zu widerrufen, was zu diesem Zeitpunkt eine Interaktion zwischen ihnen erfordert. Im DLC-Factories-Protokoll können alle Verträge zum Zeitpunkt der Erstellung der Produktionssystems erstellt werden und es ist keine weitere Interaktion erforderlich; jedoch kann jede Partei dennoch eine Reihe von Verträgen unterbrechen, indem sie die aktuelle sichere und veröffentlichbare Version onchain bringt.

    Wenn Produktionssystemsteilnehmer nach dem Abschluss des Vertrags interagieren können, können sie ihn verlängern – allerdings können sie nicht entscheiden, einen anderen Vertrag oder andere Orakel zu verwenden, bis alle zuvor unterzeichneten Verträge ausgereift sind (es sei denn, sie gehen onchain). Obwohl es möglicherweise möglich ist, dieses Manko zu beseitigen, ist dies derzeit der Kompromiss für die reduzierte Interaktivität im Vergleich zum DLC-Channels-Protokoll, das willkürliche Vertragsänderungen jederzeit durch gegenseitigen Widerruf ermöglicht.

    Wir danken Conduition dafür, dass sie uns über unseren Fehler in der letzten Ausgabe unseres Newsletters informiert haben und dafür, dass sie geduldig geantwortet haben.

Änderungen an Diensten und Client-Software

In diesem monatlichen Feature heben wir interessante Updates zu Bitcoin-Wallets und -Diensten hervor.

Releases und Release-Kandidaten

Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte ziehen Sie ein Upgrade auf neue Releases in Betracht oder helfen Sie dabei, Release-Kandidaten zu testen.

  • ● BTCPay Server 2.0.6 enthält einen “Sicherheitsfix für Händler, die Rücksendungen/Pull-Zahlungen onchain mit automatisierten Auszahlungsverarbeitern verwenden.” Ebenfalls enthalten sind mehrere neue Funktionen und Fehlerbehebungen.

Bedeutende Änderungen im Code und in der Dokumentation

[Bemerkenswerte 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 #31397 verbessert den Orphan-Auflösungsprozess, indem alle potenziellen Peers, die fehlende Elterntransaktionen bereitstellen können, verfolgt und genutzt werden. Bisher verlagerte sich der Auflösungsprozess ausschließlich auf den Peer, der die verwaiste Transaktion ursprünglich bereitgestellt hat. Falls der Peer nicht antwortete oder eine notfound-Nachricht zurückgab, gab es keinen Wiederholungsmechanismus, was wahrscheinlich zu Transaktionsdownload-Fehlern führte. Der neue Ansatz versucht, die Elterntransaktion von allen Kandidaten-Peers herunterzuladen, während die Bandbreiteneffizienz, Zensurresistenz und effektive Lastverteilung beibehalten werden. Dies ist besonders vorteilhaft für den ein-Elternteil-ein-Kind (1p1c) Package Relay und bereitet den Boden für den empfänger-initiierten BIP331 Ancestor Package Relay vor.

  • ● Eclair #2896 ermöglicht das Speichern der partiellen Signatur eines MuSig2 Peers anstelle einer traditionellen 2-von-2 Multisig-Signatur, als Voraussetzung für eine zukünftige Implementierung von einfachen Taproot Channels. Das Speichern dieser Signaturen erlaubt einem Node, eine Commitment-Transaktion einseitig zu broadcasten, wenn dies nötig ist.

  • ● LDK #3408 führt Dienstprogramme zur Erstellung statischer Rechnungen und deren entsprechenden Offers im ChannelManager ein, um asynchrone Zahlungen in BOLT12 gemäß den Spezifikationen der BOLTs #1149. Anders als das reguläre Dienstprogramm zur Erstellung von Offers, das den Empfänger erfordert, um online zu sein, um Rechnungsanfragen zu bedienen, ermöglicht das neue Dienstprogramm Empfängern, die häufig offline sind. Diese PR fügt auch fehlende Tests für das Bezahlen statischer Rechnungen hinzu (siehe Newsletter #321) und stellt sicher, dass Rechnungsanfragen abgerufen werden können, wenn der Empfänger wieder online kommt.

  • ● LND #9405 macht den Parameter ProofMatureDelta konfigurierbar, welcher die Anzahl der Bestätigungen bestimmt, die erforderlich sind, bevor eine Channel Announcement im Gossip-Netzwerk verarbeitet wird. Der Standardwert ist 6.