Miniscript

Anna möchte mit ihrem eigenen Schlüssel wie gewohnt auf ihre Coins zugreifen. Eine digitale Signatur weist die Berechtigung zur Zahlung nach. Sie wird mit einem privaten Schlüssel erzeugt, also einem geheimen Zahlenwert, der dabei nicht offengelegt wird. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Zusätzlich möchte Anna einen Weg für Peter vorsehen: Mit seinem Schlüssel soll er die Coins nach 144 Blöcken seit der Bestätigung dieses Outputs ausgeben dürfen. Diese Absicht heißt spending policy, also ein Regelwerk zum Ausgeben der Coins. Miniscript hilft, daraus eine präzise Beschreibung für die Wallet zu machen. Peter benötigt weiterhin seinen Schlüssel; Warten ersetzt ihn nicht. Das Beispiel zeigt alternative Zugangswege, keinen automatischen Transfer und keine Erkennung eines Schlüsselverlusts bei Anna. [1] [2] [10]

Eine in Worten formulierte Regel ist noch kein Programm, das das Netzwerk prüft. Ein Compiler kann dafür einen konkreten Miniscript-Ausdruck wählen und ihn in Bitcoin Script übersetzen. Ein Output Descriptor beschreibt anschließend die Skripte zusammen mit Schlüsseln und gegebenenfalls deren Ableitungspfaden; eine Prüfsumme kann vor Abschreibfehlern schützen. Beim Ausgeben prüft das Netzwerk das tatsächliche Skript und die vorgelegten Daten, nicht den ursprünglichen Satz. Miniscript ergänzt keine neue Anweisung und ändert keine Konsensregel. Nicht jedes denkbare Skript in Bitcoin Script lässt sich damit ausdrücken. [1] [3] [6]

Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. Die 144 Blöcke in Peters Beispiel zählen ab der Bestätigung des Outputs, also eines bestimmten Betrags mit festgelegten Ausgabebedingungen. Das ist weder ein exakt gemessener Tag noch die Zeit seit der Wallet-Erstellung. Relative Wartebedingungen schreibt Miniscript als older(n); dahinter stehen CSV und das nSequence-Feld des ausgebenden Inputs, dessen Bedeutung für die Altersprüfung BIP 68 festlegt. after(n) verwendet dagegen CLTV und das absolute nLockTime, also eine feste Blockhöhe oder Zeitgrenze. Die Wallet muss die Transaktionsfelder richtig setzen und alle weiteren Bedingungen erfüllen. Höhen- und Zeitbedingungen dürfen nicht unvereinbar kombiniert werden; bloßes Warten versendet nichts. [1] [7] [8] [9] [11]

Die Beschreibung der Regeln allein reicht nicht. Die Wallet muss Daten liefern, die einen zulässigen Weg erfüllen: etwa Signaturen oder ein Geheimnis mit dem geforderten Hash, dessen preimage. Ein Hash ist ein digitaler Fingerabdruck von Daten; hier wird geprüft, ob das vorgelegte Geheimnis den verlangten Fingerabdruck ergibt. Eine solche Erfüllung heißt satisfaction; die nötigen Eingabedaten sind Teil des Witness der Transaktion. Beim Verbinden von Zweigen muss unter Umständen eine Teilbedingung auf vorgesehene Weise falsch bleiben, damit ein anderer Weg gewählt wird. Das heißt dissatisfaction und macht nicht die gesamte Zahlung ungültig. Software kann einen passenden Weg zusammensetzen, aber keinen fehlenden privaten Schlüssel und kein unbekanntes Geheimnis erfinden. [1] [12]

PSBT ist ein Format zum Austausch einer vorbereiteten Transaktion samt Zusatzdaten zwischen Wallet und Signiergeräten. PSBT-Unterstützung allein genügt nicht: Software und Hardware Wallet müssen den verwendeten Descriptor und seine Bedingungen verstehen. Bitcoin Core führte mit Version 24 die reine Beobachtung von Miniscript in P2WSH ein, mit Version 25 das Signieren und mit Version 26 die Verwendung in Taproot-Deskriptoren. Coins beobachten zu können bedeutet deshalb nicht, sie ausgeben zu können. Prüfen Sie beim Einrichten auf einem vertrauenswürdigen Display Schlüssel, erforderliche Signaturen, Wartezeiten und sämtliche Alternativwege, soweit das konkrete Gerät dies unterstützt. [3] [4] [5]

Eine Seed Phrase stellt Schlüssel wieder her. Diese Sicherung besteht aus einer Wortfolge, aus der die Wallet ihre Schlüssel ableiten kann. Bei eigenen komplexen Bedingungen verrät sie aber möglicherweise nicht, wie diese mit anderen Schlüsseln und dem Skript verbunden wurden. Sichern Sie den exakten Descriptor mit Prüfsumme, die Schlüsselzuordnung, Ableitungspfade sowie die Unterscheidung zwischen Empfangs- und Wechselgeldadressen. Netzwerk, Adressbereich und Startpunkt der Suche in der Transaktionshistorie gehören separat dokumentiert. Ein öffentlicher Descriptor ist kein privater Schlüssel, kann aber die Zahlungshistorie offenlegen. Testen Sie vor der Nutzung die Wiederherstellung einer beobachtenden Wallet und jeden vorgesehenen Ausgabeweg in Regtest oder Signet. [5] [6]

pk(), older(), after() und sha256() stehen für Signaturen, Wartebedingungen oder ein verlangtes Geheimnis. and_v(), or_d() und thresh() verbinden Bedingungen. Wrapper wie v: passen das Auswertungsverhalten an, ohne die Bedeutung des Teilausdrucks zu ändern. Die Typen B, V, K und W legen fest, wie Komponenten Elemente auf dem Stack, der Arbeitsfläche des Skripts, weitergeben; nicht jedes Paar passt zusammen. Die Typprüfung kann daher unvereinbare Kombinationen erkennen. Wem Anna vertrauen sollte und ob ihr Ersatzweg sinnvoll ist, entscheidet sie nicht. [1] [2]

Die Struktur erlaubt es, Skript- und Witness-Größe, Operationen, Signaturprüfungen und Stack-Elemente vor dem Ausgeben zu analysieren. Das hilft, die Kosten verschiedener Wege abzuschätzen und Überschreitungen zulässiger Grenzen zu erkennen. Entscheidend ist der Kontext: P2WSH bettet Bedingungen in SegWit ein, während Tapscript die in Taproot verwendeten Skripte bezeichnet. Ihre Grenzen unterscheiden sich teilweise. Neben Konsensregeln gelten übliche Regeln für die Weiterleitung von Transaktionen. Ein Analyseergebnis bescheinigt deshalb nicht, dass jede Wallet den vorgesehenen Ablauf beherrscht. [1]

Der öffentliche Schlüssel dient zur Prüfung von Signaturen und muss nicht geheim bleiben. Die Malleability-Analyse untersucht, ob ein Außenstehender aus einer gültigen satisfaction eine andere gültige machen kann. Die Garantien setzen unter anderem voraus, dass der Angreifer keine privaten Schlüssel der Beteiligten besitzt, nicht mehr preimages als der ehrliche Nutzer kennt und nur eine satisfaction sieht. Außerdem werden nicht wiederholte öffentliche Schlüssel und übliche Annahmeregeln vorausgesetzt; ein Miner kann andere Möglichkeiten haben als ein gewöhnlicher weiterleitender Node. Das schützt nicht pauschal vor böswilligen Beteiligten, verlorenen Backups oder einem schlecht entworfenen Verwahrungsmodell. Diese Fragen brauchen eine eigene Prüfung. [1]

Ein Compiler kann dieselben Regeln auf unterschiedliche Weise mit verschiedenen Skript- und Witness-Größen ausdrücken. Er wählt anhand eines Kostenmodells. Eine Zweigmarkierung wie 9@ in der Policy-Eingabesprache ist ein Hinweis auf die relative Nutzungshäufigkeit, weder eine Signaturzahl noch eine Netzwerkberechtigung. Eine andere Kompilierung kann ein anderes Skript und damit andere Adressen erzeugen. Für die Wiederherstellung reicht es daher nicht, die Regeln erneut in eigenen Worten zu formulieren und zu kompilieren. Wichtig sind die exakt gesicherte Darstellung, geprüfte abgeleitete Adressen und ein getesteter Signierweg. [2] [5]