OP_EQUALVERIFY

L'octet 0x88 est le point de contrôle au milieu du plus ancien modèle de script de bitcoin. Il ne laisse rien derrière lui lorsqu'il réussit et arrête net l'exécution lorsqu'il échoue, si bien qu'une entrée qui fournit la mauvaise clé ne produit pas un paiement échoué, mais une transaction invalide qu'aucun nœud ne relaiera. C'est ici que se décide généralement si votre portefeuille a signé avec la bonne clé.

Comment cela fonctionne

OP_EQUALVERIFY retire deux éléments de la pile, les compare octet par octet, puis soit poursuit en silence, soit met fin au script.

Au moment où il s'exécute dans une dépense héritée, la pile contient deux chaînes de 20 octets. L'une est l'empreinte à laquelle la sortie s'est engagée lorsque les bitcoins sont arrivés, peut-être des années plus tôt. L'autre est l'empreinte de la clé publique que celui qui dépense vient de fournir. Un seul bit qui diffère sur ces 20 octets met fin à l'évaluation, sans possibilité de rattrapage : Bitcoin Script ne gère pas les exceptions et ne prévoit pas de seconde tentative.

Une réussite ne renvoie rien sur la pile. C'est toute la raison d'être de la forme fusionnée, et c'est pourquoi le script pay-to-public-key-hash de 25 octets peut se terminer sur une vérification de signature plutôt que sur un booléen résiduel dont personne ne veut. L'interpréteur de Bitcoin Core met en œuvre la fusion à la lettre, en exécutant le cas de comparaison puis en enchaînant sur le cas général d'assertion, de sorte qu'il s'agit d'un seul chemin de code et non de deux chemins similaires.

Le schéma se répète dans tout le langage. Chaque opcode de vérification fusionné se situe exactement un octet au-dessus de son équivalent simple : 0x87 et 0x88 pour l'égalité, 0xac et 0xad pour la vérification de signature, 0xae et 0xaf pour l'ancien opcode multisig. Lorsqu'une condition doit être remplie avant que quoi que ce soit d'autre puisse se produire, les auteurs de scripts choisissent l'octet supérieur.

Où le rencontre-t-on

L'endroit le plus clair pour rencontrer OP_EQUALVERIFY est un message de rejet plutôt qu'un explorateur de blocs.

Diffusez une transaction signée avec une clé qui ne correspond pas à l'adresse et Bitcoin Core répond par mandatory-script-verify-flag-failed, en nommant l'opération OP_EQUALVERIFY en échec dans la parenthèse qui suit. En pratique, cette erreur signifie presque toujours une chose : le dispositif de signature a dérivé sa clé depuis un chemin ou une phrase de récupération différents de ceux qui possèdent les bitcoins. Restaurer un portefeuille sous un mauvais chemin de dérivation puis tenter de dépenser produit exactement cela.

Les scripts décodés le montrent aussi clairement. Toute sortie payant une adresse qui commence par 1 s'affiche comme un script de cinq éléments avec cet opcode en quatrième position, et bitcoin-cli decodescript imprime le même assembleur pour un script de rachat que vous collez.

OP_EQUALVERIFY vs OP_VERIFY

OP_EQUALVERIFY est un test précis auquel une assertion est soudée, et OP_VERIFY est l'assertion seule. La forme générale, l'octet 0x69, ne sait rien de ce qui a produit la valeur qu'elle examine ; elle retire un seul élément et exige que cet élément soit vrai. OP_EQUALVERIFY effectue la comparaison et l'exigence ensemble en un seul octet, ce qui explique que les deux soient rarement écrits séparément. Recourez à la forme générale lorsque la condition provient d'une opération arithmétique, d'une vérification de verrou temporel ou d'un test de préimage qui n'est pas une simple égalité. Recourez à la forme fusionnée chaque fois que la question est bien de savoir si deux chaînes d'octets correspondent, ce qui, dans une dépense à clé unique, est toujours le cas.