Aller au contenu
buybitcoinsmart

Glossaire / Référence pour développeurs

OP_CHECKMULTISIG

Qu'est-ce qu'OP_CHECKMULTISIG ?
OP_CHECKMULTISIG vérifie en une seule étape un groupe de signatures par rapport à une liste de clés publiques, et les dépenses Taproot ne peuvent pas l'utiliser du tout car il empêche la vérification par lots.

Spécifié dans BIP-11.

L'octet 0xae est ce qui a rendu possible la conservation partagée : il dépile un nombre de clés, autant de clés publiques, un nombre de signatures requises, autant de signatures, puis un élément de trop. Le consensus autorise jusqu'à 20 clés dans un seul appel. C'est la raison pour laquelle une entreprise peut exiger que trois dirigeants sur cinq approuvent un retrait sans qu'aucun d'eux ne puisse agir seul.

Comment cela fonctionne

La vérification est une seule passe sur deux listes plutôt qu'une recherche. L'opcode parcourt les signatures dans l'ordre et essaie chacune contre les clés publiques successives, de sorte que les signatures doivent apparaître dans le même ordre relatif que les clés auxquelles elles appartiennent. Présentez un 2-sur-3 valide avec les deux signatures interverties et le script échoue, ce qui est une cause courante de confusion lorsque des personnes assemblent à la main des dépenses multisig.

La pile est laissée avec un élément de moins, et cela a toujours été le cas. L'implémentation d'origine dépilait un élément supplémentaire qu'elle n'utilisait jamais, un bug qui ne pouvait pas être supprimé sans casser tous les bitcoins existants. Les signataires ont appris à empiler d'abord un élément jetable, et le BIP-147 a fermé la malléabilité qui en résultait en exigeant que cet élément soit vide, à partir du bloc 481 824.

C'est dans le calcul du coût que cela fait mal. Un appel nu est facturé comme 20 opérations de signature, quel que soit le nombre de clés qu'il contient réellement, sauf si un opcode de petit nombre le précède immédiatement, auquel cas la facturation correspond à ce nombre. Un bloc est limité à 80 000 unités de coût d'opération de signature, et la politique de relais en autorise au plus 15 dans une seule entrée pay-to-script-hash. C'est ce chiffre de politique, et non la limite propre de l'opcode de 20, qui explique pourquoi les adresses de script plafonnent à quinze cosignataires.

Tapscript l'a retiré purement et simplement. Le BIP-342 a fait échouer l'opcode et sa variante de vérification à vue à l'intérieur d'une feuille Taproot, parce que vérifier un lot de signatures Schnorr par rapport à une liste en une seule opération fait échec à la vérification par lots qui rend Schnorr intéressant.

Où le rencontre-t-on

La sortie 2-sur-2 qui finance chaque canal Lightning utilise OP_CHECKMULTISIG, ce qui place à lui seul l'opcode dans une large fraction des dépenses de script du réseau. Les trésoreries d'entreprise, les arrangements de séquestre sur les anciennes places de marché pair-à-pair et le stockage à froid des plateformes d'échange construits avant Taproot l'utilisent aussi, généralement sous forme de 2-sur-3 à l'intérieur d'un hachage de script.

Les appels nus, où les clés figurent directement dans la sortie sans hachage devant elles, sont standard pour le relais jusqu'à trois clés et ne sont presque jamais utilisés, parce que l'expéditeur paie pour chaque clé et que tout l'arrangement est public avant qu'un seul bitcoin ne bouge. En 2014, ce format est brièvement devenu un moyen de stocker des fichiers sur la chaîne, ce qui explique en partie pourquoi les arguments sur le stockage de données refont surface dès que quelqu'un touche à la politique de relais.

Si vous mettez en place une conservation partagée maintenant, votre portefeuille produira plus probablement un arrangement Taproot utilisant l'alternative comptée, ou un script P2WSH si la compatibilité compte plus que les frais.

OP_CHECKMULTISIG vs multisig P2SH

OP_CHECKMULTISIG est une instruction et le multisig P2SH est une façon de l'empaqueter. L'opcode indique comment un quorum est vérifié ; l'empaquetage indique que le quorum est caché derrière un hachage et révélé au moment de la dépense. La même instruction peut apparaître dans une sortie nue avec les clés à la vue de tous, dans un script de rachat derrière une adresse commençant par 3, ou dans un script témoin derrière une adresse bc1q, et les trois diffèrent énormément en coût et en confidentialité tout en exécutant une logique de vérification identique. Ce que vous ne pouvez pas faire, c'est utiliser l'instruction dans une feuille Taproot, ce qui explique pourquoi les quorums modernes sont construits à partir d'un opcode entièrement différent.

À ne pas confondre avec

Questions fréquentes

Pourquoi ma dépense multisig échoue-t-elle alors que toutes les signatures sont valides ?

Presque toujours parce que les signatures ne sont pas dans le bon ordre. L'opcode parcourt les deux listes en parallèle, de sorte que les signatures doivent apparaître dans le même ordre relatif que leurs clés publiques, et il ne revient pas réessayer une clé précédente.

Cet opcode est-il retiré du bitcoin ?

Il fonctionne encore dans les scripts hérités et SegWit version 0 et continuera de fonctionner, car les bitcoins existants en dépendent. Les feuilles Taproot ne peuvent pas l'utiliser, de sorte que les nouveaux quorums sont construits avec OP_CHECKSIGADD, qui compte les signatures vérifiées une par une.

À lire ensuite

Termes associés

Plus de termes : Référence pour développeurs

Lire cette page en anglais