Bitcoin Script est un langage qui exprime des conditions de dépense. Chaque sortie de transaction — un montant assorti de conditions pour son prochain usage — porte ces conditions. Quiconque veut la dépenser doit les remplir. Script aide donc à répondre à une question simple : cette transaction est-elle autorisée à utiliser ces fonds précis ?
Alice reçoit 20 000 sat, soit vingt mille des plus petites unités du bitcoin. Le réseau n’ouvre pas un compte à son nom : il crée une sortie de transaction, un montant accompagné d’une condition pour le dépenser plus tard. Tant qu’elle n’est pas dépensée, cette sortie est appelée UTXO. Dans un paiement courant, la condition exige une signature avec la clé correspondante. Lorsqu’Alice paie ensuite quelqu’un, son portefeuille sélectionne cette sortie, la désigne par une nouvelle entrée de transaction et crée une signature numérique. Il utilise la clé privée sans l’envoyer à qui que ce soit ; les autres vérifient la signature avec la clé publique. Connaître l’adresse de réception d’Alice ne suffit pas. Les conditions de la sortie d’origine figurent dans le champ scriptPubKey, et Bitcoin Script précise comment vérifier qu’elles sont remplies. Un nœud n’est pas un agent qui reconnaît Alice : c’est un ordinateur qui contrôle des règles. Outre la signature, il doit notamment vérifier que cette même sortie n’a pas déjà été dépensée. La transaction n’est valide que si toutes les règles applicables sont respectées. [4] [2]
Pour les paiements ordinaires, le portefeuille construit les conditions. Suivez ses consignes de sauvegarde : une restauration normale à partir des mots dans un portefeuille compatible n’impose pas automatiquement de conserver chaque script à la main. Dans une configuration plus complexe, telle que Multisig, qui nécessite plusieurs signatures, les mots d’un seul participant peuvent toutefois ne pas décrire tout le dispositif de dépense. Pour un usage courant, mieux vaut un portefeuille aux procédures éprouvées que des scripts assemblés manuellement en hexadécimal. Les descripteurs de sorties décrivent le type de script, les clés et leur dérivation ; ils aident ainsi à déterminer ce qu’un portefeuille restauré doit rechercher. Une clé privée seule peut ne pas suffire à restaurer une configuration plus complexe. Conservez aussi les scripts nécessaires et les informations sur l’origine des clés, c’est-à-dire leur point de départ et leur méthode de dérivation, puis vérifiez les voies de dépense prévues. [11]
Les chapitres suivants présentent l’encodage des conditions dans une transaction ; il n’est pas nécessaire de le connaître pour payer au quotidien. Le champ scriptSig et la partie appelée witness apportent les données de vérification. Un hash est une empreinte des données ; un verrou temporel interdit la dépense avant un seuil donné. On peut imaginer la pile comme un empilement d’éléments manipulés par le dessus. Script traite les données à l’aide d’une pile : il y place des valeurs, puis des instructions appelées opcodes les retirent, les comparent ou les traitent autrement. Les instructions de signature vérifient les signatures ; les clés privées et la création des signatures ne font pas partie de cette vérification. Le langage peut combiner signatures, conditions de hachage et verrous temporels. Il ne possède pas de boucles générales et n’est pas Turing-complet : il ne peut pas exprimer tous les calculs possibles dans un langage de programmation universel. Le nœud doit appliquer les règles exactes correspondant au type de sortie et à la version du script. [1] [3]
Une sortie P2PKH (Pay to Public Key Hash) prend habituellement la forme OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. L’entrée fournit une signature et une clé publique dans son scriptSig. La validation vérifie que le hachage de la clé publique correspond à la valeur inscrite dans la sortie, puis vérifie la signature. Connaître seulement l’adresse ou la clé publique ne suffit donc pas à effectuer cette dépense. La clé privée est utilisée par le portefeuille qui signe, et non par le nœud qui contrôle la transaction. [1]
P2SH, conformément à BIP16, inscrit le hachage d’un script dans la sortie. L’entrée qui dépense cette sortie fournit le redeemScript correspondant, c’est-à-dire le script révélé lors de la dépense, ainsi que les données nécessaires. Son scriptSig ne peut contenir que des instructions qui empilent des données. Le nœud vérifie d’abord la correspondance du hachage, puis évalue redeemScript avec les éléments restants de la pile. Un hachage correct ne suffit pas à lui seul : les conditions de ce script doivent également être satisfaites. [5]
Avec SegWit version 0, les données de vérification sont déplacées dans la partie de la transaction appelée witness. Il s’agit d’une liste de données, et non d’un script en soi. P2WPKH utilise une signature et une clé publique ; P2WSH contient aussi un witnessScript dont le hachage SHA256 doit correspondre à la sortie. Avec SegWit natif, scriptSig est vide. Dans le cas d’une encapsulation dans P2SH, il contient uniquement l’instruction qui empile le programme witness correspondant ; les données de vérification proprement dites restent dans le witness. [6]
La vérification d’une signature utilise un message dérivé de la transaction selon une procédure définie. Le mode SIGHASH détermine les parties que la signature protège contre les modifications. Il est donc incorrect de supposer que chaque signature couvre toute la transaction. BIP143 inclut toujours, pour les opérations de signature de SegWit version 0, le montant de la sortie dépensée. Le portefeuille doit connaître les données correctes et le mode choisi ; lors du contrôle, Script n’évalue pas l’intention humaine du signataire. [7]
Selon BIP341, Taproot permet de dépenser une sortie P2TR (Pay to Taproot) de deux façons. La voie par clé vérifie une signature de Schnorr avec la clé publique de sortie, sans révéler de script. La voie par script révèle au contraire le script choisi et un bloc de contrôle, appelé control block, qui prouve le lien cryptographique entre ce script et la sortie. Les autres scripts de l’arbre n’ont pas à être révélés. Les règles du script révélé dépendent aussi de la version de la feuille correspondante. [8]
BIP342 définit Tapscript pour les feuilles Taproot de version 0xc0. Les instructions de signature utilisent ici des signatures de Schnorr, et OP_CHECKSIGADD permet de construire une condition exigeant plusieurs signatures. L’ancien OP_CHECKMULTISIG est interdit lorsqu’il est exécuté. L’ancienne limite de longueur de script de 10 000 octets et la limite de 201 opcodes comptés selon les anciennes règles ne s’appliquent pas. Un budget dérivé de la taille du witness limite les opérations de signature ; les limites de la pile subsistent. Les limites d’une version ne doivent donc pas être présentées comme des propriétés générales de Script. [9]
Les règles de consensus déterminent la validité d’une dépense dans un bloc. Le caractère standard désigne les règles locales supplémentaires d’un nœud pour accepter des transactions non confirmées dans son Mempool et les propager ; il ne s’agit pas d’un processus de normalisation. Une transaction valide au regard du consensus n’est donc pas nécessairement propagée couramment. OP_SUCCESSx dans Tapscript exige une attention particulière : après la réussite des contrôles précédents, sa reconnaissance lors du décodage fait réussir la validation du script avant l’exécution normale et les contrôles de la pile. Ce mécanisme réserve des possibilités d’extension futures ; ce n’est pas une condition de dépense ordinaire et sûre. [10] [9]
Pour une vision complète, lisez aussi Transaction, Multisig, Timelock, Taproot. Cette entrée est également citée par Hash, SHA-256, Règles de consensus, Timelock.