Der Newsletter dieser Woche beschreibt einen Vorschlag, der mehrere Ableitungspfade (Derivation paths) in einem einzigen Outputskript-Deskriptor zulässt und enthält unseren üblichen Abschnitt mit Zusammenfassungen erwähnenswerter Änderungen an beliebten Bitcoin Infrastrukturprojekten.

News

  • ● Multi-Ableitungspfad-Deskriptoren: Andrew Chow hat einen BIP-Vorschlag in der Bitcoin-Dev Mailingliste geposted, um Spezifizierung zweier verwandter BIP32-Pfade für HD-Schlüsselgenerierung in einem einzelnen Deskriptor zu erlauben. Der erste Pfad würde zur Erzeugung von Adressen verwendet werden, an die eingehende Zahlungen empfangen werden können. Der zweite Adresspfad wäre für interne Zahlungen innerhalb des Wallets gedacht; nämlich zur Rückgabe von Wechselgeld an das Wallet, nachdem eine UTXO ausgegeben wurde.

    Für besseren Datenschutz verwenden die meisten Wallets separate Pfade zur Erzeugung externer und interner Adressen wie per BIP32 spezifiziert. Ein externer Pfad, der für den Empfang von Zahlungen verwendet wird, kann mit weniger vertrauenswürdigen Geräten geteilt werden. Z.B. durch Hochladen auf einen Webserver, damit Zahlungen empfangen werden können. Der interne Pfad, der nur für Wechselgeld verwendet wird, wird möglicherweise nur dann benötigt, wenn der private Schlüssel ebenfalls benötigt wird, so dass diese beiden die gleiche Sicherheit erhalten könnte. Würde der Beispiel-Webserver kompromittiert und die externen Adressen sickerten durch, würden Angreifer jedes Mal erfahren, ob der Nutzer Geld erhalten hat, wie viel er erhalten hat und wann das Geld ursprünglich ausgegeben wurde - aber sie würden nicht unbedingt erkennen können, wie viel Geld in dieser Transaktion an den Empfänger gesandt wurde, und sie würden auch nichts über Ausgaben erfahren, die ausschließlich Wechselgeld ausgeben.

    Antworten von Pavol Rusnak und Craig Raw wiesen darauf hin, dass das Trezor- und das Sparrow Wallet bereits das von Chow vorgeschlagene System unterstützen. Rusnak fragte auch, ob ein einzelner Deskriptor in der Lage sein sollte, mehr als zwei zusammenhängende Pfade zu beschreiben. Dmitry Petukhov merkte an, dass bis dato nur interne und externe Pfade weite Verbreitung fänden und dass zusätzlichen Pfaden in bestehende Wallets keine klare Bedeutung zukomme. Dies könne Interoperabilitätsprobleme verursachen. Er schlug vor, das BIP auf zwei Pfade zu beschränken und dass für zusätzliche Pfade Folge-BIPs geschrieben werden sollten.

Nennenswerte Code- und Dokumentationsänderungen

Erwähnenswerte Änderungen diese Woche in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), und Lightning BOLTs.

  • ● Core Lightning #5441 aktualisiert hsmtool um den Vergleich der BIP39 Passphrase mit dem HD seed, der vom CLN internen Wallet verwendet wird, zu vereinfachen.

  • ● Eclair #2253 fügt Support für das Weiterleiten von verdeckten Zahlungen (blinded payments) wie in BOLTs #765 spezifiziert hinzu (siehe Newsletter #187).

  • ● LDK #1519 fügt immer das htlc_maximum_msat-Feld in channel_update-Nachrichten ein, was erforderlich wird wenn BOLTs #996 in die LN-Spezifikation aufgenommen wird. Die im Pullrequest angegebene Begründung für die Änderung ist die Vereinfachung des Nachrichtenparsings.

  • ● Rust Bitcoin #994 fügt einen LockTime-Typ hinzu, der zusammen mit nLockTime und BIP65 OP_CHECKLOCKTIME-Feldern verwendet werden kann. Locktime-Felder in Bitcoin können entweder eine Blockhöhe oder den Unix epoch time-Wert enthalten.

  • ● Rust Bitcoin #1088 fügt notwendige Strukturen für kompakte Blöcke, wie in BIP152 beschrieben, sowie eine Methode zur Erstellung eines kompakten Blocks aus einem regulären Block, hinzu. Kompakte Blöcke ermöglichen es einem Node seinen Peers mitzuteilen, welche Transaktionen der Block enthält, ohne vollständige Kopien dieser Transaktionen übermitteln zu müssen. Wenn ein Peer diese Transaktionen bereits empfangen und gespeichert hat, als sie noch unbestätigt waren, müssen die Transaktionen nicht erneut heruntergeladen werden. Das spart Bandbreite und beschleunigt die Weiterleitung neuer Blöcke.