OP_CHECKSIG

Presque tous les bitcoins jamais dépensés sont passés par cet opcode, l'octet 0xac. Il construit un condensé de la transaction selon l'octet de sighash collé à la fin de la signature, vérifie la signature par rapport à la clé publique, et pousse true ou false. S'il pousse false, la dépense n'a pas lieu, ce qui résume tout ce que signifie posséder du bitcoin en code.

Comment cela fonctionne

OP_CHECKSIG dépile deux éléments, la clé publique en premier et la signature en dessous, puis effectue trois tâches distinctes que l'on confond généralement en une seule.

D'abord, il détermine ce qui a été signé. Le dernier octet d'une signature ne fait pas partie de la signature : c'est un indicateur qui précise quelles parties de la transaction le condensé a couvertes. La valeur de loin la plus courante est 0x01, ce qui signifie toutes les entrées et toutes les sorties, de sorte que modifier une partie quelconque de la transaction après la signature l'invalide. La recette de construction de ce condensé a été remplacée deux fois, par le BIP-143 pour les dépenses SegWit version 0 et de nouveau par le BIP-341 pour Taproot, les deux fois pour empêcher que le coût de hachage croisse avec le carré de la taille de la transaction.

Ensuite, il vérifie l'encodage, et le bitcoin est ici d'une rigueur inhabituelle. Une signature héritée doit être un DER valide, d'au plus 72 octets y compris l'octet d'indicateur, avec la valeur S dans la moitié inférieure de l'ordre de la courbe. La règle d'encodage strict est arrivée avec le BIP-66 en juillet 2015, et ce basculement a laissé orphelins six blocs en un seul après-midi parce que plusieurs grands pools construisaient sur des en-têtes de bloc qu'ils n'avaient pas validés. Cela reste la démonstration la plus claire que le minage et la validation sont deux métiers différents.

Troisièmement, il vérifie. Les dépenses héritées et SegWit version 0 utilisent ECDSA sur secp256k1. Tapscript utilise à la place une signature Schnorr de 64 octets selon le BIP-340, exige qu'une vérification échouée pousse un élément vide plutôt que toute autre chose, et facture au script 50 unités de poids de budget pour chaque signature vérifiée.

Où le voit-on

OP_CHECKSIG clôt presque tous les scripts qui existent. Une sortie héritée se termine par lui, une dépense SegWit native à clé unique exécute le même modèle avec le même opcode final même si ces octets n'apparaissent jamais sur la chaîne, et les scripts d'engagement de Lightning se terminent par lui après leurs branches de timelock et de révocation.

L'exception mérite d'être connue lorsqu'on lit un explorateur de blocs. Une dépense Taproot par chemin de clé n'exécute aucun script : le nœud vérifie une seule signature directement par rapport à la clé de 32 octets dans la sortie. Il n'y a pas d'assemblage à afficher et aucun opcode à désigner, ce qui explique précisément pourquoi ce type de dépense est le moins cher et le plus privé disponible, et pourquoi une adresse bc1p qui n'est jamais dépensée que par son propriétaire est identique sur la chaîne à toutes les autres.

OP_CHECKSIG vs OP_CHECKSIGADD

OP_CHECKSIGADD existe parce qu'OP_CHECKSIG ne peut pas être compté. Dans un script multipartite, il faut savoir combien des signatures présentées étaient bonnes, et l'ancienne conception répondait à cela par un seul opcode qui absorbait d'un coup toute une liste de clés et de signatures. Tapscript l'a remplacé par un opcode qui vérifie une signature et ajoute un à un total courant sur la pile, de sorte qu'une politique 2-sur-3 devient une courte séquence se terminant par une comparaison à 2. Le changement n'est pas cosmétique : compter une signature à la fois est ce qui permet de vérifier les signatures Schnorr par lots, et la vérification par lots est à l'origine de la vitesse de validation de Taproot.