OP_CHECKSIGADD

Der Opcode nimmt drei Elemente vom Stapel, eine Signatur, einen laufenden Zähler und einen öffentlichen Schlüssel, und legt den Zähler entweder unverändert oder um eins erhöht zurück. BIP-342 wies ihm den Opcode 186 zu und deaktivierte im selben Zug OP_CHECKMULTISIG, sodass jedes Taproot-Script-Multisig so geschrieben wird. Der praktische Gewinn ist, dass eine Schwellenwertrichtlinie nicht mehr bei 20 Schlüsseln endet.

Wie es funktioniert

Ein Schwellenwert in tapscript ist eine Kette von Signaturprüfungen mit einem Zählerstand, der zwischen ihnen weitergegeben wird, und einem Vergleich am Ende.

Ausgeschrieben liest sich ein Zwei-von-drei so: den ersten öffentlichen Schlüssel ablegen, OP_CHECKSIG, den zweiten ablegen, OP_CHECKSIGADD, den dritten ablegen, OP_CHECKSIGADD, 2 ablegen, OP_NUMEQUAL. Die Ausführung läuft von links nach rechts. OP_CHECKSIG lässt 1 oder 0 auf dem Stapel, und jedes OP_CHECKSIGADD nimmt einen öffentlichen Schlüssel vom Stapel, nimmt diesen laufenden Gesamtwert vom Stapel, nimmt die für diesen Schlüssel angebotene Signatur vom Stapel und legt den Gesamtwert um 1 erhöht zurück, wenn die Signatur verifiziert wurde. Der abschließende Vergleich entscheidet, ob es genügend waren.

Ein Unterzeichner, der nicht teilnimmt, liefert eine leere Byte-Zeichenkette anstelle einer Signatur. Der Opcode sieht sie, behandelt diese Position als nicht signiert und gibt den Zählerstand unverändert zurück, was ein einzelnes Byte im Witness kostet. Das ist der ganze Mechanismus, und er beseitigt das Dummy-Stapelelement, das OP_CHECKMULTISIG wegen eines Off-by-one-Fehlers in der ursprünglichen Implementierung erforderte.

Aus der Prüfung eines Schlüssels gegen eine Signatur folgen zwei Konsequenzen. Die Verifizierung lässt sich bündeln: ein Node kann jede Schnorr-Signatur im Block in eine einzige aggregierte Prüfung werfen, statt Kandidatenschlüssel der Reihe nach zu testen, was einen großen Teil der Validierungsbeschleunigung von Taproot ausmacht. Und die Anzahl der Schlüssel wird durch das Validierungsbudget von tapscript begrenzt, das 50 Gewichtseinheiten pro geprüfter Signatur verbraucht, statt durch eine feste Obergrenze, die in den Opcode geschrieben ist.

Wo es auftritt

OP_CHECKSIGADD erscheint in jedem Taproot-Script, das mehr als einen Unterzeichner benötigt, was in Wallet-Software meist einen Deskriptor und nicht rohes Script bedeutet.

Bitcoin Core stellt es als die Fragmente multi_a und sortedmulti_a innerhalb eines tr()-Deskriptors bereit, sodass ein Quorum aus drei Schlüsseln als tr(internalkey,multi_a(2,KEY1,KEY2,KEY3)) geschrieben wird und die Software die Opcode-Kette für Sie erzeugt. Miniscript behandelt es genauso, und Hardware-Geräte, die Taproot-Richtlinien unterstützen, signieren diese Scripts, ohne die Anordnung im Voraus kennen zu müssen.

Das Design ändert auch, wie Sie ein Quorum gestalten können. Statt eines Blatts, das alle drei Schlüssel enthält, kann ein Taptree drei getrennte Blätter mit je zwei Schlüsseln enthalten, eines für jedes mögliche Paar, und eine Ausgabe offenbart dann nur das Paar, das tatsächlich signiert hat. Das kostet mehr an Script-Blättern und spart einen öffentlichen Schlüssel im Witness, und es ist eine echte Verbesserung der Privatsphäre gegenüber der Veröffentlichung des vollständigen Schlüsselsatzes bei jeder Ausgabe.

OP_CHECKSIGADD vs. OP_CHECKMULTISIG

OP_CHECKSIGADD und OP_CHECKMULTISIG zählen beide Signaturen gegen eine Menge von Schlüsseln, und nur einer von beiden funktioniert in einem Taproot-Blatt. OP_CHECKMULTISIG bleibt in Legacy- und SegWit-Scripts der Version 0 vollkommen gültig, sodass das bc1q-Multisig, das seit Jahren verwendet wird, nicht betroffen ist und keine Migration benötigt.

Innerhalb von tapscript sind OP_CHECKMULTISIG und OP_CHECKMULTISIGVERIFY ausdrücklich deaktiviert. Jenseits des Einsatzorts zählen drei Unterschiede: der alte Opcode begrenzt ein Script auf 20 öffentliche Schlüssel und der neue hat keine solche Zahl, der alte erfordert ein zusätzliches Dummy-Element auf dem Stapel, das laut BIP-147 später per Konsensregel leer sein musste, und der alte kann nicht gebündelt verifiziert werden, weil ein Verifizierer nicht im Voraus weiß, zu welchem Schlüssel jede Signatur gehört.