Tapscript

Le BIP-342 le définit, et l'octet de version de feuille 0xc0 marque une branche d'un taptree comme tapscript plutôt que comme autre chose inventé plus tard. Par rapport au langage de script utilisé partout ailleurs, il supprime la limite de 201 opérations autres que des push et le plafond de taille de script de 10 000 octets, et il désactive OP_CHECKMULTISIG. Si vous dépensez un bitcoin Taproot en révélant un script, c'est dans ce langage que ce script est écrit.

Comment cela fonctionne

Une dépense tapscript remet au réseau trois éléments sur la pile témoin : les arguments que le script demande, le script lui-même, et un bloc de contrôle prouvant que le script appartient à l'adresse.

La vérification des signatures a changé en premier. OP_CHECKSIG et OP_CHECKSIGVERIFY attendent désormais une clé publique x-only de 32 octets et une signature Schnorr de 64 octets, ou 65 octets lorsqu'un type de sighash non par défaut est ajouté. OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY échouent d'emblée, et OP_CHECKSIGADD prend leur place.

La comptabilisation des ressources a changé dans un second temps, et c'est la partie qui a de réelles conséquences. Les anciens compteurs, 201 opérations par script et un décompte global de sigops, ont disparu. Chaque entrée reçoit à la place un budget de validation qui commence à 50 unités de poids plus la taille de son propre témoin, et chaque vérification de signature réussie en soustrait 50. Vous achetez du travail de vérification avec des octets, ce qui est une règle plus claire qu'un décompte fixe et signifie qu'un script peut contenir autant de clés que vous êtes prêt à payer.

Deux portes ont été laissées ouvertes pour de futures mises à niveau. Les opcodes 80, 98, 126 à 129, 131 à 134, 137, 138, 141, 142, 149 à 153 et 187 à 254 sont devenus OP_SUCCESS : si l'un d'eux apparaît n'importe où dans le script, même dans une branche qui ne s'exécute jamais, le script réussit immédiatement. Les clés publiques de toute longueur autre que 32 octets sont traitées comme un type de clé inconnu et passent. Les deux règles permettent à un futur soft fork d'attribuer un comportement réel sans hard fork. Ce qui subsiste inchangé est le plafond de 520 octets sur un seul élément de pile et la limite de pile de 1 000 éléments.

Où vous le voyez

Tapscript apparaît chaque fois qu'une sortie Taproot est dépensée de la manière difficile, en révélant une branche au lieu de signer avec la clé agrégée.

L'usage réel le plus lourd est le stockage de données. Une inscription ordinals est une enveloppe tapscript, un bloc de contenu poussé 520 octets à la fois entre OP_FALSE OP_IF et OP_ENDIF, et elle existe sous cette forme précisément parce que tapscript a supprimé la limite de script de 10 000 octets et que la remise sur le témoin s'y applique. Quoi que vous pensiez de cette pratique, c'est la raison pour laquelle la plupart des gens ont vu une dépense tapscript sans le savoir.

Les usages plus proches d'un épargnant sont plus discrets. Les branches de récupération à verrouillage temporel, les solutions de repli de séquestre et les scripts de canal plus récents de Lightning existent tous sous forme de feuilles tapscript, et Bitcoin Core peut les construire et les signer via Miniscript dans un descripteur tr().

Tapscript vs Bitcoin Script

Bitcoin Script est la famille ; tapscript en est un membre. Trois versions de script sont actives sur le réseau en même temps : le langage hérité, le langage de la version SegWit 0, et tapscript, et un nœud choisit entre elles d'après la sortie dépensée, non d'après quoi que ce soit dans le script lui-même.

Cela compte lorsque vous copiez un script depuis un tutoriel. Un deux sur trois écrit avec OP_CHECKMULTISIG est valide dans une sortie P2WSH et invalide dans une feuille de taptree. Un script qui pousse 4 000 octets dépasse la limite de consensus dans un script témoin P2WSH et convient dans tapscript. Mêmes opcodes dans le script, des règles différentes en dessous.