Vorschlag: Bitcoin-Deskriptoren sollen Hash-Urbilder tragen können wie private Schlüssel

Victoria Shinder04 October 2026, 13:002 Min. Lesezeit

Ein Beitrag auf Delving Bitcoin vom 4. Oktober schlägt vor, Output-Deskriptoren so zu erweitern, dass sie das Geheimnis hinter einer Miniscript-Hashsperre enthalten können, nicht nur dessen Hash. Die vorgeschlagene Syntax lautet sha256(preimage(HEX)), ebenso für hash256, ripemd160 und hash160 – möglicherweise als neues BIP, das BIP 379, die Spezifikation für Miniscript-Deskriptoren, ergänzt.

Die Lücke. Ein Deskriptor kann bereits einen privaten Schlüssel tragen, geschrieben als pk(WIF) oder mit einem xprv, und listdescriptors gibt ihn mit private=true aus. Für ein Urbild gibt es nichts Vergleichbares. Der Autor stieß darauf bei einer Aufgabe der TABConf, für die ein Urbild offengelegt werden musste: Die Wallet von Bitcoin Core konnte es nicht annehmen. Der einzige Weg war, das Feld PSBT_IN_SHA256 oder eines der anderen Hash-Felder mit einem externen Werkzeug einzufügen, bevor walletprocesspsbt oder finalizepsbt den Witness vervollständigen konnte.

Die Begründung. Eine Signatur bezieht sich auf eine bestimmte Transaktion und kann daher nie in einem Deskriptor stehen. Ein Urbild hängt dagegen, einmal erzeugt oder übergeben, nur vom Skript ab und bleibt unbegrenzt gültig. Damit sei es, so der Beitrag, dieselbe Art langlebiges Geheimnis wie ein privater Schlüssel. Er zitiert eine frühere Diskussion bei Bitcoin Core, wonach Deskriptoren den Großteil der Signierdaten der Wallet ersetzen könnten – alles außer Signaturen und Urbildern – und hält die Ausnahme für Urbilder für unnötig.

Wie es funktionieren soll.

• Alle vier Hash-Fragmente werden zu einem Skript, das zuerst prüft, ob die Erfüllung 32 Byte lang ist. Ein gültiges Urbild hat daher immer genau 32 Byte, auch bei ripemd160 und hash160; jede andere Länge würde der Parser ablehnen.
• Der Parser hasht das Urbild und baut denselben Knoten wie bei der Hash-Form. Skript, Typ und Witness-Größe ändern sich nicht, und die Nichterfüllung des Fragments braucht weiterhin kein Geheimnis.
• Eine ausdrückliche Markierung preimage(...) ist nötig, weil bei sha256 und hash256 ein roher 32-Byte-Hexwert sowohl Urbild als auch Hash sein könnte.
• Die öffentliche Form des Deskriptors zeigt den Hash, nur die private Form das Urbild. In Bitcoin Core würden Urbilder zusammen mit den Schlüsseln verschlüsselt gespeichert und an den Miniscript-Satisfier übergeben.

Grenzen. Urbilder, die man erst beim Ausgeben erfährt, etwa von einer Gegenpartei in einem HTLC, liefen weiter über PSBT-Felder. Der Beitrag weist auch darauf hin, dass ein offengelegtes Urbild öffentlich ist; gut gebautes Miniscript verlangt aber auf jedem Ausgabepfad eine Signatur, sodass ein Urbild allein nie zum Ausgeben reicht. Offen sind die Syntax der Markierung und die Frage, ob das in BIP 379 oder in ein eigenes BIP gehört.

Was das bedeutet

Das ist eine Designdiskussion, kein Code. Bei Wallets auf Miniscript-Basis sind Hashsperren in zeitgesperrten Wiederherstellungs- und Swap-Skripten verbreitet, und ihre Geheimnisse liegen heute außerhalb der Sicherung, die die Schlüssel enthält. Ein Deskriptor, der beides trägt, würde solche Wallets aus einer einzigen Zeichenkette wiederherstellbar machen – und diese Zeichenkette bräuchte dann denselben Schutz wie eine Seed-Phrase.