Opcode

Anna veut payer Pierre. Son portefeuille prépare la transaction et les signatures nécessaires ; les nœuds vérifient ensuite si elle pouvait dépenser les pièces choisies. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Un nœud est un logiciel qui vérifie les transactions et les blocs et communique avec les autres participants du réseau. Bitcoin Script est le langage d’une partie de ces contrôles. Un opcode est une étape, par exemple vérifier une signature. Anna n’écrit pas les instructions à la main pour un paiement courant. Mais un nœud ne peut croire un nom de propriétaire ou la mention « signé » : il doit évaluer les conditions. Un script valide n’est qu’une partie de la validation complète. [1] [4]

Une représentation lisible peut afficher OP_DUP ou OP_CHECKSIG. Ce sont des noms destinés aux humains ; dans le script, des codes d’un octet les représentent. L’octet est une unité courante de mesure des données. D’autres parties contiennent des données, comme une clé publique. La clé publique sert à vérifier les signatures et n’a pas besoin de rester secrète. Les instructions de la famille OP_PUSHDATA indiquent combien d’octets suivants doivent être insérés comme données. Ces octets ne sont pas réexécutés comme des instructions. Pensez à la différence entre « ajouter du sel » dans une recette et l’ingrédient versé dans le récipient. [1] [2]

Imaginez une pile de fiches dont on prend celle du dessus. La pile de travail du script fonctionne ainsi. OP_DUP copie l’élément supérieur ; OP_DROP le retire. Exécuter OP_DUP puis OP_DROP sur une pile non vide la ramène à son contenu initial. Vous n’avez pas dupliqué des pièces, seulement des données de travail. L’absence d’un élément nécessaire peut faire échouer l’évaluation. L’ordre et la représentation exacte comptent aussi. [1]

OP_EQUAL prend les deux éléments supérieurs, compare leurs octets et les remplace par le résultat. OP_EQUALVERIFY échoue immédiatement s’ils diffèrent ; s’ils sont identiques, il continue sans laisser ce résultat sur la pile. Aucune de ces deux opérations ne vérifie à elle seule une signature. Tout le monde peut présenter deux copies identiques d’une clé publique. Il faut le contrôle de signature approprié pour établir que quelqu’un pouvait signer le message demandé. [1] [4]

OP_CHECKSIG vérifie une signature avec une clé publique et un message construit à partir de la transaction, sans dévoiler la clé privée. La clé privée est une valeur numérique secrète qui permet de créer cette signature. Le paramètre sighash détermine les parties couvertes ; tous les modes ne signent pas tout. Les anciens scripts et SegWit version 0 utilisent ECDSA, un algorithme de signature. Tapscript, les règles de scripts de Taproot, utilise un autre algorithme, Schnorr, pour les clés habituelles de 32 octets. Le nom de l’instruction ne suffit pas sans ce contexte. [1] [3]

Une condition peut permettre une dépense normale ou un autre chemin de récupération. OP_IF et OP_ELSE choisissent une branche à partir d’une valeur de la pile ; OP_ENDIF termine la partie conditionnelle. Bitcoin Script ne comporte pas de boucles générales pouvant se répéter arbitrairement. Cela ne permet pas d’ignorer tout ce qui figure dans une branche non exécutée. Certaines instructions sont contrôlées dès la lecture du script : leur type et la version des règles comptent. [1] [3]

CLTV, l’instruction OP_CHECKLOCKTIMEVERIFY, peut imposer une limite absolue, par exemple une hauteur de bloc précise, c’est-à-dire sa position dans la chaîne. CSV, OP_CHECKSEQUENCEVERIFY, impose avec les règles d’ancienneté un délai relatif depuis la confirmation de la sortie dépensée. Une sortie est un montant reçu auparavant, assorti de conditions de dépense. Ces instructions vérifient des champs de la transaction ; elles ne démarrent pas de minuteur, n’envoient pas d’argent et ne remplacent pas une signature. Il faut combiner le bon verrou temporel avec les autres conditions. [7] [8] [9]

Avant de lire un exemple technique, déterminez s’il utilise les anciens scripts, SegWit ou Tapscript. Tapscript ajoute OP_CHECKSIGADD pour combiner les vérifications de signatures. À l’inverse, OP_CHECKMULTISIG échoue lorsqu’il est exécuté ; ses règles l’ignorent dans une branche non exécutée. Les noms ne se contredisent pas : les environnements diffèrent. Une liste d’opcodes n’est pas un jeu de pièces universellement interchangeables entre formats. [1] [3] [6]

BIP 342 réserve la famille OP_SUCCESSx à de futures extensions de Tapscript. Une fois les contrôles précédents réussis, en rencontrer un au décodage permet de sauter avec succès les contrôles de script suivants, même dans une branche non exécutée. Un octet identique au sein de données insérées ne compte pas. C’est une possibilité d’évolution des règles, pas une nouvelle protection déjà activée. Une condition fondée sur un sens futur encore indéfini peut ne pas protéger les fonds comme prévu. [1] [3]

Un Full Node vérifie les règles de validité de manière autonome, mais peut être plus strict pour accepter et propager les transactions non confirmées. Bitcoin Core v29.0 refuse par défaut de propager les transactions utilisant une instruction OP_SUCCESSx dans Tapscript, alors que le consensus peut les admettre dans un bloc. Pour lire un exemple, identifiez la version, les données initiales, la couverture des signatures et les cas d’échec. Une syntaxe lisible ne prouve pas la sécurité d’un portefeuille ; en usage courant, vous confiez ces vérifications à un logiciel examiné. [1] [5]