Glossar / Entwicklerreferenz
Redeem-Skript
Auch bekannt als Redeem script.
- Was ist ein Redeem-Skript?
- Ein Redeem-Skript ist der vollständige Ausgabevertrag, der hinter einem Pay-to-Script-Hash-Output verborgen liegt, vom Ausgebenden am Ende des Signaturskripts bereitgestellt und gehasht, um zu prüfen, ob es übereinstimmt.
Spezifiziert im BIP-16.
BIP-16 erlaubte es einem Absender, statt eines ganzen Vertrags einen 20-Byte-Hash zu bezahlen, und das Redeem-Skript ist der Vertrag, für den dieser Hash steht. Es muss in ein einziges Stack-Element passen, also sind 520 Byte die harte Obergrenze. Verlieren Sie diese Bytes, sind Ihre privaten Schlüssel wertlos, was das Redeem-Skript zu einem Teil Ihrer Sicherung macht und nicht zu einem Teil Ihrer Software.
Wie es funktioniert
Ein Redeem-Skript ist unsichtbar, solange die Coins still liegen. Der Output, der sie hält, enthält nur einen Hash und ein Muster, das der Konsens erkennt, durchgesetzt im gesamten Netzwerk ab dem 1. April 2012 bei Block 173.805. Niemand, der Ihnen zahlt, erfährt etwas über die Bedingungen, und ein Block-Explorer ebenso wenig.
Offenbart wird es bei der Ausgabe. Das Signaturskript legt alle Argumente auf den Stack, die der Vertrag braucht, und endet mit dem serialisierten Vertrag selbst. Ein validierender Node nimmt dieses letzte Element, hasht es, vergleicht das Ergebnis mit dem Hash im Output und deserialisiert das Element erst dann und führt es als Code gegen den verbleibenden Stack aus. Beide Stufen müssen bestehen, und weil das Feld, das es trägt, nichts außer Push-Operationen enthalten darf, kann das Skript selbst kein Verhalten einschmuggeln, bevor es geprüft wird.
Das häufigste Redeem-Skript überhaupt ist gar kein Vertrag. Ab 2017 verpackten Wallets, die SegWit-Einsparungen wollten und die dennoch von alter Software bezahlt werden konnten, ein Witness-Programm in einen Script-Hash, sodass das Redeem-Skript 22 Byte umfasst: ein Versionsbyte und einen 20-Byte-Schlüsselhash, ohne etwas auszuführen. Millionen von Auszahlungsadressen von Börsen, die mit 3 beginnen, verbergen genau das und nichts weiter.
Wo Sie es sehen
Bitcoin Core übergibt Ihnen eines, wann immer Sie eine Script-Adresse erstellen, und sein Befehl decodescript verwandelt das Hex wieder in lesbaren Assembly-Code. In einem Deskriptor wird das Skript ausdrücklich als sh(wpkh(...)) oder sh(multi(...)) geschrieben, was die moderne Art ist, es festzuhalten, denn Deskriptor-Wallets kamen in Bitcoin Core 0.21.0 im Januar 2021 auf und machten die alte Gewohnheit, bloße Adressen zu importieren, überflüssig.
Der Verlustfall ist real und konkret. Eine Seed-Phrase erzeugt Schlüssel neu. Sie erzeugt kein beliebiges Skript neu und kann Ihnen nicht die öffentlichen Schlüssel der anderen Mitunterzeichner nennen, sodass eine 2-von-3-Anordnung, bei der jeder Beteiligte nur seinen eigenen Seed aufbewahrt hat, nicht ausgegeben werden kann. Menschen haben Coins verloren, obwohl sie einen vollständigen Satz privater Schlüssel besaßen und keine Aufzeichnung des Skripts, in das diese Schlüssel angeordnet waren. Bewahren Sie den Deskriptor zusammen mit jeder Seed-Sicherung auf und stellen Sie einmal daraus wieder her, mit einem kleinen Betrag, bevor die Adresse etwas enthält, das Ihnen fehlen würde.
Das andere, was Sie wissen sollten, ist die Größenbegrenzung. Fünfzehn komprimierte öffentliche Schlüssel plus ihre Push-Präfixe und die umgebenden Opcodes ergeben 513 Byte, was gerade noch passt; ein sechzehnter passt nicht. Diese Obergrenze, nicht eine Regel über Multisig, begrenzt eine Script-Adresse auf fünfzehn Mitunterzeichner.
Redeem-Skript vs. Witness-Skript
Ein Redeem-Skript und ein Witness-Skript besetzen denselben konzeptionellen Platz in zwei verschiedenen Epochen, und der Unterschied liegt darin, wohin die Bytes reisen und wie sie festgeschrieben werden. Ein Redeem-Skript wird mit einem 160-Bit-Hash festgeschrieben und reist im Signaturskript mit vier Gewichtseinheiten pro Byte. Ein Witness-Skript wird mit einem vollständigen 256-Bit-SHA-256 festgeschrieben und reist im Witness mit einer Gewichtseinheit pro Byte, weshalb dieselbe Policy bei der Ausgabe etwa ein Viertel kostet. Eine verschachtelte Anordnung nutzt beide zugleich: Das Redeem-Skript ist das 34-Byte-Witness-Programm und das Witness-Skript ist der eigentliche Vertrag. Wenn Sie eine Sicherung für ein verschachteltes SegWit-Multisig festhalten, brauchen Sie beide schriftlich, nicht nur eines.