Qu'est-ce que le langage de script Bitcoin ?

Le script Bitcoin est le langage de programmation qui régit toutes les transactions sur le réseau Bitcoin. Il s'agit d'un langage simple, basé sur une pile, qui définit les conditions exactes dans lesquelles les bitcoins peuvent être dépensés ; chaque nœud complet du réseau l'exécute à chaque fois qu'une transaction est validée. Sans lui, Bitcoin ne serait qu'un registre de chiffres, dépourvu de tout mécanisme permettant de déterminer à qui appartient quoi.

La plupart des utilisateurs n’ont jamais directement affaire au langage de script Bitcoin. Leurs portefeuilles s’en chargent en arrière-plan. Mais chaque fois que vous envoyez ou recevez des BTC, deux petits programmes s’exécutent simultanément sur des milliers d’ordinateurs, vérifiant si les conditions de dépense ont été respectées. Comprendre comment cela fonctionne permet de mieux saisir pourquoi Bitcoin est structuré ainsi, et ce qu’il peut et ne peut pas faire par rapport à des plateformes comme Ethereum.

Cet article explique le fonctionnement de Bitcoin Script, passe en revue les principaux types de transactions qu'il permet, présente la mise à jour Taproot qui a modernisé la couche de script en 2021, et fait le point sur le débat autour de l'opcode « covenant » en juin 2026.

Gérez vos bitcoins en toute sécurité grâce à l'auto-conservation Application Bitcoin.com Wallet.

Points clés à retenir

• Bitcoin Script est un langage de programmation basé sur une pile, intégré au protocole Bitcoin, qui définit les conditions dans lesquelles toute sortie Bitcoin peut être dépensée.
• Chaque transaction Bitcoin comprend deux scripts : un script de verrouillage (ScriptPubKey) défini par le destinataire et un script de déverrouillage (ScriptSig) fourni par l'émetteur. Les deux doivent s'exécuter correctement pour que la transaction soit valide.
• Le script Bitcoin n'est délibérément pas Turing-complet. Il ne comporte ni boucles, ni état persistant entre les exécutions, et la taille des scripts est strictement limitée. Cela garantit que chaque script s'arrête, ce qui constitue une fonctionnalité de sécurité et non une limitation.
• Le langage de script a évolué à travers cinq formats principaux : P2PK, P2PKH, P2SH, SegWit (P2WPKH/P2WSH) et Taproot (P2TR), chacun élargissant le champ des possibilités tout en restant rétrocompatible.
• La version Taproot (novembre 2021) a introduit les signatures Schnorr, des chemins de dépenses basés sur le protocole MAST pour renforcer la confidentialité, ainsi que Tapscript, un langage de script mis à jour doté d'un mécanisme intégré permettant des mises à jour futures plus fluides.
• Parmi les cas d'utilisation concrets basés sur Bitcoin Script, on peut citer les portefeuilles à signatures multiples, les transactions à délai de déblocage, les contrats à délai de déblocage basé sur un hachage (qui constituent le fondement du réseau Lightning), les services d'entiercement et les contrats à journal discret.
• Contrairement aux contrats intelligents d'Ethereum, Bitcoin Script est « sans état » : chaque script s'exécute de manière totalement isolée, sans avoir connaissance d'aucune autre transaction. Il s'agit là d'un choix architectural délibéré.
• En 2026, le domaine le plus dynamique du développement des scripts Bitcoin concerne les opcodes de covenant, en particulier OP_CTV (BIP-119) et OP_CAT (BIP-347), qui permettraient aux scripts de définir les conditions auxquelles une transaction de dépense doit se conformer. Aucun des deux n'a encore été activé sur le réseau principal.

Qu'est-ce que le script Bitcoin ?

Bitcoin Script est un langage de script sans état, basé sur une pile, intégré au protocole Bitcoin. Chaque sortie de transaction sur le réseau Bitcoin comporte un script de verrouillage (appelé ScriptPubKey) qui spécifie les conditions d'utilisation des fonds. Toute personne souhaitant utiliser ces fonds doit fournir un script de déverrouillage (appelé ScriptSig, ou, dans les transactions SegWit et Taproot, les données de témoin) qui satisfait à ces conditions.

Ce langage tire sa structure du Forth, un langage de programmation minimaliste basé sur une pile, développé dans les années 1960. À l'instar de Forth, Bitcoin Script se lit de gauche à droite, fonctionne sur une structure de données appelée « pile » et utilise la notation polonaise inversée (RPN), dans laquelle les opérateurs suivent leurs opérandes plutôt que de les précéder. Il exécute une instruction à la fois, ne comporte pas de boucles et ne conserve aucune mémoire persistante entre les exécutions.

Ce dernier point est celui que la plupart des gens découvrent en premier lorsqu’ils se familiarisent avec Bitcoin Script au niveau du protocole : ce langage n’est délibérément pas Turing-complet. Un langage Turing-complet est capable d’effectuer n’importe quel calcul à condition de disposer de suffisamment de temps et de ressources. Bitcoin Script, de par sa conception, en est incapable, et les raisons de ce choix ont une grande importance pour le fonctionnement du réseau.

Fonctionnement du script Bitcoin : le modèle en pile

Pour comprendre le fonctionnement de Bitcoin Script, il faut d'abord comprendre le principe de la pile. Une pile est une structure de données qui fonctionne selon le principe « dernier entré, premier sorti » (LIFO). Imaginez une pile d'assiettes : on ne peut ajouter ou retirer des éléments qu'au sommet. Dans Bitcoin Script, les données sont poussées sur la pile et les opcodes (codes d'opération) manipulent ce qui se trouve au sommet.

Lorsqu'un nœud Bitcoin valide une transaction, il exécute deux scripts à la suite :

1. Le script de déverrouillage (ScriptSig ou témoin) fournies par la personne qui dépense les pièces. Cela permet d'ajouter des données à la pile, généralement une signature numérique et une clé publique.
2. Le script de verrouillage (ScriptPubKey) liée à la dépense de la sortie. Elle contient des opcodes qui agissent sur les données de la pile et vérifient si les conditions de dépense sont remplies.

Si le script s'exécute sans erreur et laisse une valeur non nulle (TRUE) sur la pile à la fin, la transaction est valide. S'il échoue ou laisse la valeur FALSE, la transaction est rejetée par le nœud et n'est jamais intégrée dans un bloc.

Cette exécution est entièrement sans état. Le script n'a aucune connaissance des transactions précédentes, aucune information sur les soldes actuels et aucune mémoire qui perdure une fois son exécution terminée. Chaque script s'exécute à chaque fois à partir de zéro, de manière isolée.

Étape par étape : une transaction P2PKH standard

Le « Pay-to-Public-Key-Hash » (P2PKH) est le type de transaction Bitcoin d'origine, utilisé depuis 2009. Les adresses P2PKH commencent par « 1 ». Voici à quoi ressemblent concrètement les champs ScriptPubKey et ScriptSig :

Script de déverrouillage (ScriptSig) :

<signature> <clé publique>

Script de verrouillage (ScriptPubKey) :

OP_DUP OP_HASH160 <hachage de la clé publique> OP_EQUALVERIFY OP_CHECKSIG

Lorsque le nœud concatène et exécute les deux ensemble, les opérations de la pile se déroulent étape par étape :

• La signature et la clé publique issues de ScriptSig sont placées sur la pile
• OP_DUP duplique la clé publique située en haut de la pile
• OP_HASH160 calcule la valeur de hachage du doublon (SHA-256 suivi de RIPEMD-160), ce qui donne une valeur de hachage de 20 octets
• Le hachage de la clé publique issu du script de verrouillage est placé sur la pile
• OP_EQUALVERIFY vérifie que les deux hachages correspondent. Si ce n'est pas le cas, l'exécution s'interrompt et la transaction échoue.
• OP_CHECKSIG vérifie que la signature correspond bien à la clé publique

Si toutes les étapes sont validées, la pile se termine par TRUE et les fonds sont débloqués. L'ensemble du processus ne prend que quelques millisecondes et se déroule de manière identique sur chaque nœud du réseau.

Les opcodes Bitcoin expliqués

Les opcodes Bitcoin sont les commandes individuelles qui composent un script. Chacune d'entre elles occupe un octet, ce qui donne 256 emplacements d'opcode possibles. Parmi ceux-ci, environ 80 sont actuellement actifs sur le réseau principal. Les autres sont soit réservés, soit désactivés, soit attribués au mécanisme de compatibilité ascendante OP_SUCCESS introduit avec Tapscript.

Les opcodes se répartissent en plusieurs catégories :

• Opcodes de transfert de données placer des valeurs telles que des clés publiques, des signatures et des hachages sur la pile
• Opcodes arithmétiques effectuer des opérations d'addition, de soustraction et de comparaison. À noter que la multiplication et la division sont désactivées.
• Opcodes cryptographiques notamment OP_SHA256, OP_HASH160 et OP_SHA1 pour le hachage, ainsi que OP_CHECKSIG pour la vérification des signatures
• Opcodes de contrôle de flux Activer la logique conditionnelle : OP_IF, OP_ELSE, OP_ENDIF, OP_NOTIF
• Opcodes de manipulation de la pile notamment OP_DUP (dupliquer l'élément du haut), OP_DROP (supprimer l'élément du haut) et OP_SWAP (échanger les deux éléments du haut)

Plusieurs opcodes ont été désactivés par Satoshi Nakamoto en 2010 après la découverte de failles dans leurs implémentations d'origine. Il s'agit notamment de OP_CAT (concaténation de deux éléments de la pile), OP_MUL (multiplication) et OP_DIV (division). Leur absence a eu des conséquences durables sur les possibilités d'expression de Bitcoin Script, et plusieurs des propositions de mise à jour de Bitcoin les plus débattues en 2026 portent sur l'opportunité de réactiver certaines d'entre elles.

Pour consulter la référence complète des codes d'opération, y compris les valeurs hexadécimales et les descriptions, rendez-vous sur la page Page « Script » du Wiki Bitcoin est la source de référence.

Pourquoi le fait de ne pas être « Turing-complet » est un atout

L'explication courante est que Bitcoin Script ne comporte pas de boucles, ce qui garantit que les scripts s'arrêtent toujours, protégeant ainsi le réseau contre une exécution infinie. C'est exact, mais cela ne rend pas pleinement compte de la situation.

Le débat plus profond porte sur la surface d’attaque. Un langage Turing-complet permet d’exprimer n’importe quel calcul. Cette expressivité est également le terrain propice aux bogues. Le langage Solidity d’Ethereum a donné lieu à certaines des vulnérabilités logicielles les plus coûteuses de l’histoire. Le piratage du DAO en 2016 a exploité une faille de réentrance dans un contrat intelligent et a entraîné des pertes d’environ 60 millions de dollars aux cours de l’époque, conduisant finalement à un hard fork controversé du réseau Ethereum. L’écosystème DeFi dans son ensemble a vu des centaines de millions de dollars s’envoler à la suite d’exploits de contrats intelligents sur plusieurs années.

Le script Bitcoin rend ce type d’attaque structurellement impossible. Il est impossible d’écrire un script Bitcoin qui appelle d’autres scripts, qui effectue une boucle jusqu’à ce qu’une condition change ou qui conserve un état entre deux transactions. Chaque script est un programme délimité, qui s'arrête et qui peut être inspecté. La taille maximale d'un script est de 10 000 octets. Le nombre maximal d'opcodes autres que « push » par script est de 201. Un validateur peut toujours calculer le coût d'exécution dans le pire des cas avant d'exécuter le script.

Pour un réseau dont la valeur s'élève à des centaines de milliards de dollars, cette prévisibilité vaut bien plus que la flexibilité à laquelle on renonce. Ethereum résout le problème du calcul illimité grâce à des limites de gaz : il facture aux utilisateurs chaque opcode exécuté et interrompt les scripts qui épuisent leur budget. Cela fonctionne, mais cela introduit sa propre complexité et ses propres modes de défaillance. Bitcoin contourne entièrement le problème de par sa conception même.

Cela dit, « ne pas être Turing-complet » ne signifie pas « ne pas être capable de traiter une logique complexe ». Bitcoin Script prend en charge les conditions de dépenses multipartites, les conditions temporelles, la révélation de préimages de hachage, ainsi que des combinaisons de tous ces éléments. Le Lightning Network, qui achemine des millions de paiements par jour, repose entièrement sur les primitives de Bitcoin Script.

Types de scripts : l'évolution de P2PKH à Taproot

La couche de script du Bitcoin a considérablement évolué depuis 2009, chaque mise à jour introduisant un nouveau format de transaction tout en restant rétrocompatible avec toutes les versions antérieures.

P2PK (Pay-to-Public-Key, 2009)

Le format d'origine, utilisé lors des premières transactions Bitcoin, notamment le paiement effectué par Satoshi à Hal Finney dans le bloc 170. Les fonds étaient liés directement à une clé publique complète plutôt qu'à son hachage. Il est aujourd’hui rarement utilisé dans les nouvelles transactions, car il expose la clé publique sur la chaîne avant la dépense, ce qui est considéré comme une mesure de sécurité moins efficace que le hachage préalable de la clé.

P2PKH (Pay-to-Public-Key-Hash, 2009)

Le format standard depuis plus d’une décennie. Le P2PKH lie les fonds à un hachage de la clé publique plutôt qu’à la clé elle-même, ce qui permet de préserver la confidentialité de la clé publique jusqu’au moment de la dépense, de générer une adresse plus courte de 20 octets et de constituer la base de toutes les adresses commençant par « 1 ». Selon les données on-chain fournies par Unchained (avril 2026), les adresses P2PKH détiennent actuellement environ 43 % de l'offre de bitcoins minés.

P2SH (Pay-to-Script-Hash, 2012, BIP 16)

Introduit via un soft fork le 1er avril 2012, le protocole P2SH a transféré la charge liée aux scripts de dépense complexes de l’expéditeur au destinataire. Au lieu d’intégrer un script de verrouillage complet dans la sortie, les sorties P2SH se limitent à un hachage de 20 octets d’un « script de rachat ». Le script complet n’est révélé qu’au moment où les pièces sont dépensées. Cela a rendu la signature multiple (multisig) accessible aux utilisateurs lambda : une configuration multisig « 2 sur 3 » ne nécessitait plus que les trois clés publiques soient visibles par l’expéditeur au moment du paiement. Les adresses P2SH commencent par « 3 ».

Pour une explication détaillée du fonctionnement de la validation P2SH au niveau du protocole, Guide des transactions de developer.bitcoin.org explique étape par étape le fonctionnement du mécanisme « redeem script ».

P2WPKH et P2WSH (SegWit natif, 2017, BIP 141)

Le Segregated Witness, activé en août 2017 au bloc 481 824, a déplacé les données de signature hors du corps principal de la transaction vers une structure « witness » distincte. Les données « witness » bénéficient d’une réduction de poids de 75 %, ce qui rend les transactions SegWit nettement moins coûteuses. Une transaction P2WPKH standard à une entrée et deux sorties pèse environ 141 octets virtuels, contre 226 vbytes pour une transaction P2PKH équivalente, selon Analyse des types d'adresses Bitcoin par Spark à partir de mars 2026. SegWit a également résolu le problème de la malléabilité des transactions, ce qui constituait une condition préalable à la mise en place du Lightning Network. Les adresses SegWit natives commencent par « bc1q ».

P2TR (Pay-to-Taproot, 2021, BIP 340/341/342)

Taproot a été activé en novembre 2021 au bloc 709 632 et constitue la mise à jour la plus importante de la couche de script de Bitcoin depuis SegWit. Il a introduit les signatures Schnorr, un nouveau type de sortie prenant en charge MAST, ainsi que Tapscript, un langage de script amélioré. Les adresses Taproot commencent par « bc1p. »

Taproot et Tapscript : comment le langage de script Bitcoin a évolué en 2021

Taproot n'est pas une simple modification. Il s'agit de trois propositions d'amélioration de Bitcoin (Bitcoin Improvement Proposals) conçues conjointement et mises en œuvre simultanément.

BIP 340 : Signatures de Schnorr

À l'origine, le Bitcoin utilisait l'algorithme ECDSA (Elliptic Curve Digital Signature Algorithm). Satoshi l'avait choisi en partie parce que les signatures Schnorr étaient alors protégées par un brevet. Ce brevet a expiré en 2008, et Taproot a finalement intégré les signatures Schnorr au protocole.

Les signatures Schnorr sont plus courtes (64 octets) que celles de l'ECDSA (71 à 73 octets). Plus important encore, elles prennent en charge l’agrégation de clés grâce à un schéma appelé MuSig2. L’agrégation de clés permet à plusieurs signataires de combiner leurs clés et signatures individuelles en une seule clé et signature agrégées, qui sont indiscernables sur la chaîne d’un paiement ordinaire à signature unique. Un portefeuille multisignature « 2 sur 3 » effectuant des dépenses via le chemin de clé coopératif de Taproot apparaît identique à un paiement standard sur la blockchain. Il s’agit là d’un réel gain en matière de confidentialité pour toute personne détenant des bitcoins dans le cadre d’un dispositif de conservation complexe.

BIP 341 : Pay-to-Taproot et MAST

P2TR introduit un nouveau type de sortie comportant deux chemins de dépense :

• A chemin d'accès effectuer des dépenses à l'aide d'une signature de Schnorr, utilisée lorsque toutes les parties sont d'accord et souhaitent opter pour la solution la plus simple et la moins coûteuse
• A chemin d'accès au script utiliser MAST (Merkelized Abstract Syntax Tree, qui est l'implémentation de ce concept dans Taproot)

MAST permet à une sortie unique de s'engager dans une arborescence de plusieurs scripts de dépense via une racine de Merkle. Lors d'une dépense, seule la condition spécifique effectivement utilisée est révélée sur la chaîne. Tous les autres chemins de dépense possibles dans l'arborescence restent masqués de manière permanente. Pour un utilisateur ayant configuré une politique de dépense complexe, par exemple « Je peux dépenser normalement, ou deux des trois mandataires peuvent dépenser après six mois, ou une clé de récupération peut dépenser après deux ans », seul le chemin effectivement exécuté apparaît sur la blockchain.

En 2024, la part de Taproot dans les transactions Bitcoin avait atteint environ 42 %, principalement grâce à l'activité liée aux inscriptions Ordinals et BRC-20, selon les données de Glassnode citées par Spark en mars 2026. Depuis lors, cette part a fluctué en fonction des conditions du marché, mais l'infrastructure est désormais la norme sur l'ensemble des principaux portefeuilles et plateformes d'échange. Page thématique « Taproot » de Bitcoin Optech suit l'évolution du protocole Taproot.

BIP 342 : Tapscript

Tapscript est la version mise à jour du langage de script utilisé pour les dépenses via « script-path » dans Taproot. Il partage la plupart des opcodes avec l'ancien Bitcoin Script, mais apporte plusieurs modifications importantes :

• OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY sont obsolètes. L'ancien opcode multisig présentait une particularité qui nécessitait, à titre de solution de contournement, d'ajouter un élément factice à la pile. Tapscript le supprime et le remplace par OP_CHECKSIGADD, qui vérifie les signatures de Schnorr une par une et en comptabilise le nombre. Les schémas de signatures multiples à seuil deviennent ainsi plus simples et moins coûteux à mettre en œuvre.
• Les limites de taille des scripts par feuille MAST ont été supprimées. Les scripts individuels au sein d'une branche Taproot peuvent désormais atteindre une taille illimitée.
• Opcodes OP_SUCCESS constituent le changement le plus novateur. Dans le script traditionnel, la rencontre d’un opcode non défini entraîne l’échec du script. Dans Tapscript, les opcodes de la plage OP_SUCCESS garantissent la réussite inconditionnelle du script. Les futurs soft forks pourront attribuer un comportement réel à ces opcodes en ajoutant des contraintes sur les conditions de leur réussite, sans nécessiter de nouvelle version du script ni de cycle complet de redéploiement à l’échelle de l’écosystème. De nouvelles fonctionnalités peuvent être ajoutées à la couche de script de Bitcoin de manière plus propre qu’à aucun autre moment de l’histoire du protocole.

Miniscript

Parallèlement à Tapscript, un projet connexe appelé Miniscript a pris une importance croissante pour les développeurs. Miniscript est une méthode structurée permettant d’écrire un sous-ensemble de Bitcoin Script qui est analysable, composable et signable de manière générique. Alors que le Script brut nécessite une construction manuelle et est difficile à auditer, les scripts Miniscript peuvent être vérifiés automatiquement pour s'assurer de leur exactitude et combinés pour former des politiques plus complexes. Miniscript n'étend pas les capacités du Script, mais rend ses fonctionnalités existantes nettement plus accessibles aux développeurs qui créent des portefeuilles et des outils de conservation.

Ce que permet Bitcoin Script : des cas d'utilisation concrets

Les types de transactions suivants sont actuellement actifs sur le réseau principal de Bitcoin ; ils reposent tous sur les primitives de Bitcoin Script :

Portefeuilles à signatures multiples (multisig) nécessitent M clés privées sur N pour autoriser une dépense. Le service de trésorerie d’une entreprise peut exiger 3 approbations sur 5 pour tout retrait. Un couple marié peut utiliser le modèle « 2 sur 2 » pour son épargne commune. Grâce à Taproot et à l’agrégation de clés Schnorr, les dépenses multisignatures coopératives sont désormais, sur la chaîne, impossibles à distinguer des transactions standard à signature unique.

Transactions à délai fixe Utilisez les opcode OP_CHECKLOCKTIMEVERIFY (CheckLockTimeVerify, ou CLTV) et OP_CHECKSEQUENCEVERIFY (CheckSequenceVerify, ou CSV) pour empêcher le transfert de fonds avant qu’une certaine hauteur de bloc ou un certain délai ne soit atteint. Parmi les applications possibles, on peut citer la planification successorale, les calendriers d'acquisition des jetons par les employés, les mécanismes d'épargne forcée et les transactions avec pénalité utilisées au sein des canaux du Lightning Network.

Contrats à verrouillage temporel par hachage (HTLC) combiner une condition de préimage de hachage avec un verrou temporel. La condition de dépense fonctionne ainsi : il faut révéler la préimage de ce hachage avant d’atteindre cette hauteur de bloc, faute de quoi les fonds sont restitués à l’expéditeur. Les HTLC constituent la primitive fondamentale du Lightning Network ; ils permettent un acheminement des paiements sans tiers de confiance à travers des chaînes de canaux entre des parties qui n’ont aucune relation directe.

Compte séquestre Ces mécanismes bloquent les fonds dans un script P2SH ou Taproot, ce qui nécessite l'accord de plusieurs parties avant leur déblocage ; en général, un arbitre tiers détient une clé de décision en cas d'égalité.

Contrats de journalisation discrets (DLC) utiliser des signatures d'adaptateur Schnorr basées sur un oracle pour permettre la conclusion de contrats financiers dont le règlement repose sur des données du monde réel, telles que des flux de prix ou les résultats d'événements, sans que l'oracle ait à détenir de fonds. Les DLC sont opérationnels sur le réseau principal Bitcoin et sont utilisés pour les produits d'options et de contrats à terme dont le règlement s'effectue en Bitcoin.

Script Bitcoin vs contrats intelligents Ethereum

Le script Bitcoin et Solidity d'Ethereum définissent tous deux les conditions dans lesquelles les fonds peuvent être transférés, mais ils représentent des choix architecturaux fondamentalement différents. Il est intéressant de procéder à cette comparaison directe, car ces différences en disent long sur les compromis que chaque réseau a acceptés.

La différence fondamentale réside dans la « statefulness ». Les contrats Ethereum stockent et modifient des données qui persistent d’une transaction à l’autre, ce qui rend possibles les protocoles de prêt, les bourses décentralisées, la gouvernance sur la chaîne et les normes de jetons. Bitcoin Script ne dispose d’aucun équivalent. Chaque script s’exécute de manière isolée, sans avoir connaissance des autres transactions.

Il s’agit d’un choix architectural délibéré, et non d’une lacune à combler. La couche de script de Bitcoin a été conçue pour une tâche spécifique : faire respecter les conditions de dépense des bitcoins, de manière prévisible et sécurisée, à grande échelle. Pour cette tâche, l’absence d’état constitue un atout. La surface d’attaque est réduite, l’exécution est déterministe parmi des millions de validateurs indépendants, et il n’existe aucune catégorie d’exploitation de contrats intelligents au niveau du protocole, car il n’y a pas de contrats avec état à ce niveau.

Les projets qui souhaitent bénéficier d’une plus grande programmabilité par rapport à Bitcoin la mettent en place par couches. Le Lightning Network gère les paiements. Les protocoles DLC gèrent les contrats financiers référencés à des données externes. Les systèmes de couche 2, tels qu’Ark et le Liquid Network, répondent à différents profils d’évolutivité. Aucune de ces approches ne nécessite de modifier le modèle de script de la couche de base.

Le débat sur le Covenant : quels changements pourraient intervenir dans le script Bitcoin ?

L'évolution du script Bitcoin a toujours été lente et prudente. Le domaine de développement le plus actif à l'heure actuelle concerne les opcodes « covenant », qui sont des propositions visant à permettre à un script de définir non seulement qui peut dépenser une sortie, mais aussi quelles doivent être les caractéristiques de la transaction qui en résulte. Il s'agit là d'un élargissement significatif de la puissance expressive du script.

Les principales propositions en juin 2026 sont les suivantes :

• OP_CTV (BIP-119, CheckTemplateVerify), rédigée par Jeremy Rubin, ajoute un seul opcode qui lie un UTXO à un modèle de dépense spécifique et prédéterminé, comprenant la version de la transaction, le délai de verrouillage, le nombre d’entrées, les séquences, le nombre de sorties et les sorties. De par sa conception, il est non récursif ; considéré comme la proposition majeure la plus prudente, il vise principalement les « vaults », le contrôle de la congestion et certaines améliorations du réseau Lightning. En avril 2026, l’OP_CTV disposait de paramètres de déploiement concrets précisant une fenêtre de signalisation « Speedy Trial », mais n’avait pas encore obtenu le large consensus communautaire requis pour son activation, selon Analyse des clauses restrictives de BlockEden pour avril 2026.
• OP_CAT (BIP-347), proposé par Ethan Heilman et Armin Sabouri, réactiverait un opcode que Satoshi avait désactivé en 2010. OP_CAT concatène deux éléments de la pile, ce qui est simple en théorie mais a des implications considérables. Associé aux signatures Schnorr, il permet une introspection des transactions de type « covenant ». Sur le réseau de test Signet de Bitcoin, OP_CAT avait généré nettement plus de transactions de développeurs que l’APO ou le CTV, selon l’analyse on-chain réalisée par sCrypt fin 2024. OP_CAT est déjà actif sur le réseau Liquid et Fractal Bitcoin, sans qu’aucune faille de sécurité ne lui ait été attribuée. Le BIP-347 dispose d’un numéro de proposition officiel et fait l’objet de recherches actives, mais son activation sur le réseau principal nécessite un consensus de la communauté qui n’existe pas encore.
• LNHANCE associe OP_CTV à OP_CHECKSIGFROMSTACK (CSFS) et OP_INTERNALKEY, dans le but d'apporter des améliorations spécifiques à la création de canaux sur le Lightning Network, notamment l'ouverture de canaux non interactifs et une gestion plus efficace des canaux multipartites.

Aucune de ces propositions n’avait été activée sur le réseau principal de Bitcoin en juin 2026. Les divergences techniques entre elles sont en grande partie surmontables. Le problème le plus épineux concerne les mécanismes d’activation. Le processus de « soft fork » de Bitcoin nécessite un large consensus, et le débat sur le « covenant » reste marqué par des tensions résiduelles issues de mises à jour controversées antérieures. Ce qui ressort clairement de ce débat, c’est que la couche de script de Bitcoin dispose d’une marge de progression significative au sein de son cadre conservateur. La question à laquelle on s’attèle concerne l’ordre de mise en œuvre et l’accord de la communauté, et non pas l’avenir du langage de script lui-même.

Conclusion

Bitcoin Script est l'infrastructure invisible qui sous-tend chaque transaction sur le réseau. La plupart des utilisateurs n’y sont jamais directement confrontés. Les portefeuilles construisent des scripts valides, les signent et les diffusent sans jamais en dévoiler les mécanismes. Mais chaque paiement, chaque canal Lightning, chaque plan à délai de déblocage et chaque coffre-fort multisig s’appuie sur le même langage de script Bitcoin basé sur une pile, intégré au protocole dès 2009.

La couche de script s'est considérablement développée depuis lors : P2SH a rendu possibles les transactions complexes, SegWit a réduit les frais et permis l'avènement de Lightning, tandis que Taproot a introduit les signatures Schnorr, la confidentialité basée sur MAST et la conception d'opcodes évolutive de Tapscript. Les propositions de « covenant » qui font actuellement l’objet de discussions animées représentent le prochain chapitre potentiel. La question de savoir si certaines d’entre elles seront activées, et selon quel calendrier, reste véritablement ouverte à la mi-2026.

Il n'est pas nécessaire d'être développeur pour comprendre le Script. Il faut toutefois reconnaître que le conservatisme de Bitcoin, ses limitations délibérées, la lenteur de ses mises à jour et son absence de complétude de Turing ne constituent pas des lacunes. Les propriétés qui rendent le Script de Bitcoin prévisible sont précisément celles qui ont permis de préserver la pureté de la couche de consensus pendant seize ans.