Ausgabe über den Schlüsselpfad

Eine Taproot-Ausgabe kann geleert werden, indem für ihren Schlüssel signiert wird oder indem ein festgeschriebenes Skript offengelegt wird, und der Schlüsselweg ist der unauffällige. BIP-341 legt diesen Witness auf genau ein Element fest, eine 64 Byte große Schnorr-Signatur unter dem Standard-Sighash, wodurch der gesamte Input 230 Gewichtseinheiten belegt, also 57,5 vbytes. Für einen Halter sehen ein gemeinsamer Tresor und eine Einzelzahlung on-chain dann gleich aus.

So funktioniert es

Ein Key-Path-Spend signiert für den Ausgabenschlüssel, der kein von jemandem gewählter Schlüssel ist: BIP-341 konstruiert ihn als Q = P + int(t)G, wobei P der interne öffentliche Schlüssel ist und t ein getaggter Hash aus P zusammen mit der Merkle-Wurzel des Skriptbaums.

Signieren bedeutet daher, dieselbe Verschiebung auf die private Seite anzuwenden. Die Referenzroutine negiert den geheimen Schlüssel zuerst, wenn der interne Punkt eine ungerade y-Koordinate hat, weil Taproot-Tweaks auf 32 Byte große x-only-Schlüssel angewendet werden, und addiert dann t modulo der Ordnung der Kurve. Das Ergebnis signiert nach BIP-340 und kommt allein auf den Witness-Stack.

Die Validierung ist ein Zähltest, bevor sie ein kryptografischer ist. Ein Node liest die 32 Bytes des Witness-Programms, scheitert sofort, wenn der Witness-Stack leer ist, und entfernt das letzte Element als Annex, wenn zwei oder mehr Elemente vorhanden sind und dieses Element mit 0x50 beginnt. Bleibt genau ein Element übrig, ist der Spend ein Key-Path-Spend, und dieses Element muss sich als BIP-340-Signatur gegen den Ausgabenschlüssel verifizieren. Nichts in diesem Verfahren sagt dem Node, ob jemals ein Skriptbaum festgeschrieben wurde.

Die Signatur ist 64 Byte groß, wenn SIGHASH_DEFAULT mit dem Wert 0x00 impliziert ist, was die gesamte Transaktion abdeckt. Sie erreicht 65 Byte, wenn ein anderes Sighash-Byte angehängt wird, und eine 65 Byte große Signatur, die 0x00 an dieser letzten Stelle trägt, wird bewusst abgelehnt: würde sie zugelassen, könnte ein Miner oder jeder weitergebende Node eine 64 Byte große Signatur auf 65 Byte auffüllen, wodurch sich die wtxid und die vom Sender beabsichtigte Gebührenrate ändern würden.

Was die Signatur abdeckt, sind höchstens 206 Byte Nachricht. Sie schreibt sich auf die Transaktionsversion und das Locktime fest, auf Hashes jedes Input-Outpoints, Betrags, vorherigen scriptPubKey und Sequenznummer sowie auf die Ausgaben.

Die Größenrechnung ergibt sich daraus. Nach BIP-141 ist das Transaktionsgewicht die Basisgröße mal drei plus die Gesamtgröße, und die virtuelle Größe ist dieses Gewicht geteilt durch vier, für eine ganze Transaktion aufgerundet. Ein Taproot-Input trägt 41 Basis-Bytes bei (ein 36 Byte großer Outpoint, ein Längenbyte für ein leeres scriptSig, eine Vier-Byte-Sequenz) und 66 Witness-Bytes (eine Stack-Anzahl, ein Längenpräfix, die Signatur), was 41 mal 3 plus 107 ergibt, also 230 Gewichtseinheiten, und damit 57,5 vbytes.

Eine Empfehlung in BIP-341 überrascht Wallet-Autoren. Eine Ausgabe ganz ohne Skripte sollte trotzdem einen Tweak festschreiben, berechnet als getaggter Hash des internen Schlüssels für sich allein, statt den internen Schlüssel unverändert zu veröffentlichen. Die Spezifikation führt aus, warum: Wenn zwei Parteien ihre Schlüssel zu einem gemeinsamen Ausgabenschlüssel addieren, kann eine von ihnen still einen Tweak einfügen, der einen Skriptpfad verbirgt, der nur von ihr allein ausgegeben werden kann, und die andere hat keine Möglichkeit, das zu bemerken.

Warum das beim Bitcoin-Kauf zählt

Die Signaturnachricht von Taproot ist der Grund, warum eine Hardware-Wallet Ihre Gebühr berechnen kann, ohne dem Computer zu vertrauen, an den sie angeschlossen ist.

Nach BIP-143, den Regeln der SegWit-Version 0, deckte die Nachricht den Betrag ab, der vom signierten Input ausgegeben wird, und nichts weiter. Ein Gerät, das einen Input einer Transaktion mit drei Inputs signierte, musste die beiden anderen Beträge erhalten und konnte sie nicht prüfen, und genau das ist die Öffnung, die ein kompromittierter Host nutzt, damit Sie weit höhere Gebühren signieren, als der Bildschirm anzeigte. BIP-341 schreibt sich auf die Beträge jedes Inputs fest, den die Transaktion ausgibt, und auf alle vorherigen scriptPubKeys dieser Inputs, sodass ein Signierer sie selbst summieren kann. Diese Aktualisierung deckt auch Script-Path-Spends ab, doch der Schlüsselweg ist der Punkt, an dem die meisten Besitzer der Geräte aus unseren 41 Wallet-Bewertungen damit in Berührung kommen.

Ihre Wallet muss die Schlüssel ableiten können, bevor irgendetwas davon greift, und über diese Bewertungen hinweg ist das Bild uneinheitlich. KeepKey ergänzte die Unterstützung für Taproot-Ausgaben in der Firmware 7.10.0 im Februar 2025. Die eigene Ankündigung von MetaMask führt Taproot weiterhin als später kommend auf, also kann MetaMask Ihnen keine bc1p-Adresse zum Empfangen geben, was auch immer der Rest ihrer Bitcoin-Unterstützung leistet.

Die Gebühren neigen pro Input um einen kleinen Betrag zum Schlüsselweg, was sich in die Richtung summiert, in der die meisten Leser kaufen. Der signierte P2WPKH-Input im eigenen Testvektor von BIP-143 trägt eine 71 Byte große Signatur und einen 33 Byte großen Schlüssel, 107 Witness-Bytes, sobald die Stack-Anzahl und die Längenpräfixe gezählt sind, was 271 Gewichtseinheiten ergibt, also 67,75 vbytes. Ein Key-Path-Input spart dagegen 10,25 vbytes, sodass ein Sparer, der 30 einzelne kleine Käufe angesammelt und sie später zusammengeführt hat, etwa 307 vbytes von dieser einen Transaktion abzieht.

Seien Sie klar darüber, was die Privatsphäre tatsächlich bringt. Ihre Ausgabebedingungen zu verbergen heißt nicht, Ihre Historie zu verbergen: Wenn die Bitcoin von einer der 63 Börsen stammen, die diese Website bewertet, hält diese Plattform bereits Ihre Ausweisdokumente und die Auszahlungsadresse, und kein Signaturformat berührt das. Verborgen bleibt, ob der Bitcoin durch einen Schlüssel oder durch ein Quorum mit einer Wiederherstellungsroute eines Anwalts geschützt war, und diese zweite Tatsache ist die, die eine Adresse angreifenswert macht.

Durchgang durch taproot_sign_key

taproot_sign_key ist die Referenzroutine, die BIP-341 veröffentlicht, um genau diesen Witness zu erzeugen, und sie umfasst insgesamt neun Zeilen Python.

Sie nimmt einen Skriptbaum, den internen geheimen Schlüssel, einen Sighash-Typ und die von BIP-340 verlangte zusätzliche Zufälligkeit. Wenn der Skriptbaum leer ist, setzt sie die Tweakeingabe auf eine leere Bytefolge; andernfalls ist diese Eingabe die Merkle-Wurzel, die der Baum-Helfer zurückgibt. Sie tweakt den internen geheimen Schlüssel mit diesem Wert, signiert den Sighash, hängt das Byte des Hash-Typs nur an, wenn der Typ nicht null ist, und gibt eine Liste mit einem Element zurück. Dieses Element ist der gesamte Witness.

Zwei Details verdienen Aufmerksamkeit. Der leere Zweig ist nicht der ungetweakte Fall, nach dem er aussieht, denn eine leere Bytefolge einzugeben lässt den Tweak als den getaggten Hash des internen Schlüssels allein stehen, und das ist genau die nicht ausgabefähige Festschreibung, die die Spezifikation für eine Ausgabe ohne Skripte empfiehlt. Und das Zufälligkeitsargument gehört zu BIP-340 und nicht zu Taproot: Sobald der Schlüssel getweakt ist, ist das Ergebnis eine gewöhnliche Schnorr-Signatur, weshalb Key-Path-Spends keine besondere Behandlung brauchen, um in Stapeln verifiziert zu werden.

Key-Path-Spend vs. P2TR

P2TR ist der Ausgabentyp, und ein Key-Path-Spend ist einer der beiden Wege, eine Ausgabe zu leeren. Eine Coin bleibt eine P2TR-Coin, egal welche Route sie später entleert. Der Unterschied zählt, wenn jemand Ihnen sagt, Taproot-Adressen seien privat: Empfangen auf eine veröffentlicht in jedem Fall einen 32 Byte großen Schlüssel und sonst nichts, während die Privatsphäre, die gemeint ist, im Moment der Ausgabe entsteht, und nur, wenn der Schlüsselweg gewählt wird.

Key-Path-Spend vs. MuSig2

MuSig2 ist eine Möglichkeit, die Signatur zu erzeugen, die ein Key-Path-Spend braucht, und keine Voraussetzung dafür. Ein einzelner Eigentümer, der mit einem einzigen Schlüssel signiert, macht bei jeder Zahlung einen Key-Path-Spend, ohne dass ein Aggregationsprotokoll im Spiel ist. Beides wird verwechselt, weil die Aggregation der interessante Fall ist: MuSig2 ermöglicht mehreren Parteien, zu einem Schlüssel und einer Signatur zu gelangen, sodass ihre Abwicklung dieselbe Route und dieselben 57,5 vbytes nimmt wie jemand, der das Mittagessen bezahlt. Es funktioniert auch umgekehrt, denn ein aggregierter Schlüssel kann in einem Skriptblatt liegen, wo das Ausgeben dieses Schlüssels ein Script-Path-Spend ist, der zufällig MuSig2 verwendet.