OP_EQUAL

L'octet 0x87 effectue la seule comparaison dont le bitcoin a réellement besoin : ces deux blobs sont-ils identiques ? La comparaison porte sur des octets bruts et non sur des nombres, ce qui explique que le langage comporte un opcode distinct pour l'égalité arithmétique. Chaque paiement que vous avez envoyé à une adresse commençant par 3 termine son script par cette seule instruction.

Comment cela fonctionne

Deux éléments sortent de la pile et un seul y retourne : un octet unique de 0x01 lorsqu'ils correspondent, ou un élément vide lorsqu'ils ne correspondent pas. Le bitcoin traite un élément vide comme faux, le résultat peut donc être testé par tout ce qui suit.

La comparaison d'octets est plus stricte qu'elle n'en a l'air. Deux valeurs qu'une personne appellerait le même nombre peuvent être des suites d'octets différentes, et cet opcode les déclare inégales. C'est le comportement correct pour son véritable rôle, qui est de comparer des hash et des préimages où la moindre différence doit faire échouer, et c'est pourquoi les résultats arithmétiques sont comparés avec OP_NUMEQUAL à la place.

La propriété intéressante est ce qu'il ne fait pas : il laisse un résultat au lieu d'agir sur un résultat. Un script ne se termine avec succès que lorsque l'élément resté au sommet est vrai, un script qui se finit par cet opcode pose donc une question et laisse le résultat faire office de réponse. La règle cleanstack de Bitcoin Core ajoute que rien d'autre ne doit rester, ce qui, pour une dépense de script hash, signifie exactement une valeur vraie et rien de plus.

Ce dernier détail a plus de conséquences qu'il n'y paraît. Le pay-to-script-hash n'est pas une règle générale sur les scripts hachés ; c'est une règle sur un motif exact de 23 octets, un opcode de hachage, une poussée de 20 octets et cet opcode à la fin. Écrivez la même logique avec la forme combinée de vérification et le traitement spécial ne s'applique plus, le script de rachat n'est jamais extrait ni exécuté, et la sortie se comporte comme une énigme de hachage ordinaire que quiconque devine la préimage peut dépenser.

Où le voit-on

Chaque sortie non dépensée sur une adresse commençant par 3 affiche le même assemblage de trois éléments sur un explorateur de blocs, se terminant ici. Il en va de même pour chaque retrait SegWit encapsulé qu'une plateforme d'échange vous a envoyé.

Il apparaît aussi dans les contrats verrouillés par hachage. Les scripts de paiement de Lightning hachent un secret et comparent le résultat à une valeur fixe, ce qui permet à un paiement d'être réglé sur plusieurs sauts dès que le destinataire révèle une préimage de 32 octets. Les échanges atomiques entre chaînes utilisent la même forme.

OP_EQUAL vs OP_EQUALVERIFY

OP_EQUALVERIFY est OP_EQUAL avec le test intégré. L'octet 0x88 effectue la même comparaison puis interrompt immédiatement le script si la réponse est fausse, ne laissant rien sur la pile lorsqu'il réussit. Choisir entre les deux dépend de ce qui suit. Utilisez la forme simple lorsque la comparaison est la réponse finale du script, comme le fait le pay-to-script-hash. Utilisez la forme de vérification lorsque la comparaison est une condition parmi d'autres et que l'exécution doit se poursuivre, comme le fait le modèle historique à clé unique avant de vérifier une signature. La forme de vérification économise aussi un octet par rapport à l'écriture de la comparaison et d'une instruction de vérification séparée, ce qui comptait bien davantage lorsque chaque octet d'un script se trouvait dans la partie non witness de la transaction, à quatre unités de poids chacun.