SIGOPS
Désigne les opérations de signature numérique nécessaires pour valider les transactions. Chaque transaction Bitcoin peut contenir plusieurs inputs, chacun pouvant nécessiter une ou plusieurs signatures pour être considéré comme valide. La vérification de ces signatures se fait grâce à l’utilisation d’opcodes spécifiques que l’on nomme les « sigops ». Concrètement, cela inclut OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY. Ces opérations font peser une certaine charge de travail sur les nœuds du réseau qui doivent les vérifier. Pour éviter des attaques DoS par inflation artificielle du nombre de sigops, le protocole impose donc une limite sur le nombre de sigops autorisées par bloc, afin de garantir que la charge de validation reste gérable pour les nœuds. Cette limite est actuellement de 80 000 sigops maximum par bloc. Pour compter, les nœuds suivent les règles suivantes :
Dans le scriptPubKey, OP_CHECKSIG et OP_CHECKSIGVERIFY comptent pour 4 sigops. Les opcodes OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY comptent pour 80 sigops. En effet, lors du comptage, ces opérations sont multipliées par 4 lorsqu’elles ne font pas partie d’un input SegWit (pour un P2WPKH, le nombre de sigops sera donc de 1) ;
Dans le redeemScript, les opcodes OP_CHECKSIG et OP_CHECKSIGVERIFY valent également 4 sigops, OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY sont comptabilisés pour 4n s’ils précèdent OP_n, ou 80 sigops dans le cas contraire ;
Pour le witnessScript, OP_CHECKSIG et OP_CHECKSIGVERIFY valent 1 sigop, OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY sont comptés pour n s’ils sont introduits par OP_n, ou 20 sigops autrement ;
Dans les scripts Taproot, les sigops sont traitées de manière différente par rapport aux scripts traditionnels. Au lieu de compter directement chaque opération de signature, Taproot introduit un budget de sigops pour chaque entrée de transaction, qui est proportionnel à la taille de cette entrée. Ce budget est de 50 sigops plus la taille en octets du témoin de l’input. Chaque opération de signature réduit ce budget de 50. Si l’exécution d’une opération de signature fait chuter le budget en dessous de zéro, le script est invalide. Cette méthode permet plus de flexibilité dans les scripts Taproot, tout en maintenant une protection contre les abus potentiels liés aux sigops, en les liant directement au poids de l’entrée. Ainsi, les scripts Taproot ne sont pas pris en compte dans la limite des 80 000 sigops par bloc.