Comment Bitcoin fonctionne réellement sous le capot

MH
Écrit par Mohamed Habbat
Temps de lecture estimé : 13 min

Chaque transaction Bitcoin est un minuscule programme. La plupart des utilisateurs n'en lisent jamais un. Vous n'en avez pas besoin. Mais si vous voulez savoir ce que votre portefeuille écrit quand vous cliquez sur envoyer, ce chapitre ouvre le capot.

Vous pouvez le sauter et utiliser Bitcoin en toute sécurité. Lisez-le et vous saurez pourquoi Bitcoin ne connaît aucun piratage de DAO par smart contract, pourquoi votre transaction reste parfois non confirmée pendant des heures, et ce que Taproot a réellement changé.

Qu'est-ce que Bitcoin Script ?

Chaque transaction Bitcoin transporte un petit programme écrit dans un langage appelé Bitcoin Script.

Script définit la règle de dépense. Quand vous envoyez des bitcoins à quelqu'un, vous ne déplacez pas des coins vers son adresse. Vous créez une sortie verrouillée par un programme Script qui précise les conditions de dépense. Pour dépenser ces coins plus tard, le destinataire doit fournir une entrée qui déverrouille le programme.

Les deux parties ont un nom. Le programme de verrouillage est le ScriptPubKey (ou script de sortie). Les données de déverrouillage forment le ScriptSig, ou, dans les formats de transaction plus récents, un Witness (témoin).

Bitcoin Script fonctionne avec une pile. Les instructions s'exécutent dans l'ordre, empilent des valeurs et les dépilent. Imaginez une pile d'assiettes où vous ne touchez que celle du dessus. Les opérations restent simples : empiler une valeur, vérifier une signature, comparer des hachages, brancher avec OP_IF.

Un nœud valide une transaction en exécutant d'abord le script de déverrouillage (qui empile les données requises), puis le script de verrouillage. Si le sommet de la pile se termine par une valeur non nulle, la transaction est valide. Sinon, le nœud la rejette.

Votre portefeuille écrit le Script pour vous. Vous ne le voyez jamais. Mais connaître le mécanisme vous dit ce que les transactions Bitcoin peuvent et ne peuvent pas faire.

Les modèles de Script courants

Les transactions Bitcoin standard utilisent un petit ensemble de modèles de Script :

Pay-to-Public-Key-Hash (P2PKH). Le format d'adresse classique commençant par « 1 ». Le script de verrouillage dit : quiconque fournit une clé publique correspondant à ce hachage et une signature valide de la clé privée associée peut dépenser ces coins. Il a construit la majeure partie des transactions Bitcoin historiques.

Pay-to-Script-Hash (P2SH). Les adresses commençant par « 3 ». Le script de verrouillage dit : quiconque fournit un script dont le hachage correspond à cette valeur, plus des entrées qui satisfont ce script, peut dépenser ces coins. P2SH a rendu possibles le multisig et les conditions complexes tout en gardant des adresses compactes.

Pay-to-Witness-Public-Key-Hash (P2WPKH). Les adresses SegWit commençant par « bc1q ». Même logique que P2PKH, mais les données de signature passent dans la partie témoin de la transaction. SegWit a réduit les frais et corrigé un vieux bug de malléabilité.

Pay-to-Taproot (P2TR). Les adresses commençant par « bc1p ». Le format le plus récent. Il utilise les signatures Schnorr et une structure en arbre pour les conditions de dépense. Une dépense simple ressemble exactement à une dépense complexe à conditions multiples, ce qui améliore la confidentialité.

OP_RETURN. Une sortie spéciale qui attache des données arbitraires à une transaction Bitcoin. La règle de standardité plafonnait historiquement ces données à 80 octets par sortie. Bitcoin Core 30, publié le 10 octobre 2025, a relevé la valeur par défaut de -datacarriersize à 100 000 octets. Les notes de version décrivent ce plafond comme pratiquement levé, puisque le plafond de standardité par transaction est atteint en premier. Consultez les notes de version de Bitcoin Core 30 et la couverture de CoinDesk pour les raisons de ce choix. Les sorties OP_RETURN sont prouvablement indépensables. Le protocole de tokens Runes et d'autres schémas d'ancrage de données les utilisent. (Les inscriptions Ordinals fonctionnent autrement. Elles intègrent les données dans le témoin Taproot via une enveloppe OP_FALSE OP_IF, pas dans OP_RETURN.)

Que sont les codes OP ?

Les codes OP (opcodes, codes d'opération) sont les commandes individuelles de Bitcoin Script. Chacun fait une seule chose.

Ceux que vous verrez le plus souvent :

OP_DUP. Duplique l'élément au sommet de la pile. Le script d'adresse standard l'utilise pour vérifier le hachage de la clé publique sans détruire la clé publique.

OP_HASH160. Dépile l'élément du sommet, lui applique SHA-256 puis RIPEMD-160, et empile le résultat. Cette fonction de hachage transforme les clés publiques en adresses Bitcoin.

OP_EQUALVERIFY. Vérifie que les deux éléments au sommet de la pile sont identiques. Sinon, le script échoue immédiatement.

OP_CHECKSIG. Dépile une clé publique et une signature, vérifie la signature contre les données de la transaction, et empile vrai ou faux. C'est l'opération fondamentale « prouvez que vous possédez ceci ».

OP_CHECKMULTISIG. Vérifie plusieurs signatures contre plusieurs clés publiques. Exige M signatures parmi N pour réussir, le script fixant M et N.

OP_CHECKLOCKTIMEVERIFY (CLTV). Fait échouer le script sauf si le locktime de la transaction atteint ou dépasse une hauteur de bloc ou un horodatage donné. Les sorties verrouillées dans le temps, que personne ne peut dépenser avant un certain point, reposent sur lui.

OP_CHECKSEQUENCEVERIFY (CSV). Comme CLTV, mais il impose des verrous temporels relatifs. La sortie reste indépensable jusqu'à ce qu'un certain nombre de blocs se soient écoulés après sa création. Les canaux de paiement du Lightning Network en dépendent.

OP_IF / OP_ELSE / OP_ENDIF. Exécution conditionnelle. Un script peut offrir plusieurs chemins de dépense, choisis au moment de dépenser par les données que fournit le dépensier.

De nombreux codes OP des débuts de Bitcoin ont été désactivés après que des chercheurs en sécurité y ont trouvé des vulnérabilités. Satoshi et les mainteneurs ont volontairement réduit l'expressivité de Script.

Que signifie « Turing-complet », et pourquoi Bitcoin ne l'est-il pas ?

Un langage Turing-complet peut simuler n'importe quel calcul, avec assez de temps et de mémoire. Pour se qualifier, il doit pouvoir boucler indéfiniment et conserver un état arbitraire entre les opérations.

Le langage de smart contracts d'Ethereum (Solidity, exécuté sur l'EVM, l'Ethereum Virtual Machine) est Turing-complet. Il exécute des boucles, conserve un état d'une transaction à l'autre et fait tourner des programmes arbitrairement complexes. Pour empêcher les boucles infinies de dévorer le réseau, Ethereum facture du « gas » pour chaque étape de calcul. Un programme tourne jusqu'à sa fin ou jusqu'à épuisement de son gas.

Bitcoin Script n'est pas Turing-complet, par conception. Pas de boucles. Pas de récursion. Pas d'état persistant entre les transactions. Chaque exécution de Script se termine en un nombre borné d'étapes. C'était un choix, pas un vestige de la technologie des débuts.

Trois raisons expliquent ce choix :

La prévisibilité. Chaque nœud du réseau Bitcoin valide chaque transaction. Si Script pouvait boucler indéfiniment, une seule transaction malveillante pourrait bloquer la validation dans le monde entier, ou forcer chaque nœud à mouliner un calcul sans limite avant de décider du sort de la transaction. Un Script borné garde la validation rapide, quelle que soit l'exotisme de la transaction.

La sécurité. Les langages expressifs offrent une surface d'attaque plus grande. L'histoire d'Ethereum est jalonnée d'exploits de smart contracts, du piratage de la DAO en 2016 aux vidages de protocoles DeFi qui ont commencé à s'accumuler en 2020. L'expressivité étroite de Bitcoin Script exclut des classes entières de vulnérabilités avant même qu'elles puissent exister.

La sûreté du consensus. Des dizaines de milliers de nœuds indépendants dans le monde doivent évaluer les règles de Bitcoin de façon identique. Des sources de données externes, un état complexe ou un calcul non borné rendraient le consensus fragile. Script garde la validation déterministe et autonome.

Vous payez cela en capacité. Bitcoin ne peut pas exécuter nativement les applications programmables ouvertes qu'Ethereum prend en charge. Les applications financières complexes, les plateformes d'échange décentralisées et les systèmes de gouvernance qui ont besoin d'un état continu vivent sur d'autres couches ou d'autres réseaux.

Quels smart contracts Bitcoin peut-il exécuter ?

Dans les limites de Script, Bitcoin exprime une gamme significative de contrats :

Le multisig. Exiger M signatures parmi N clés désignées avant que les fonds ne bougent. Un multisig 2 sur 3 signifie que deux des trois détenteurs de clés, quels qu'ils soient, peuvent autoriser une transaction, mais qu'aucun ne peut agir seul. Les trésoreries d'entreprise, les montages successoraux et les prestataires de conservation fonctionnent ainsi.

Les contrats à verrou temporel. Les fonds restent gelés jusqu'à une hauteur de bloc ou une date donnée. Les calendriers de vesting, les obligations avec période de blocage et des constructions plus complexes les utilisent tous comme briques de base.

Les canaux de paiement du Lightning Network. Une combinaison de multisig et de verrous temporels relatifs permet à deux parties de transiger instantanément hors chaîne et de ne régler que le solde final sur la chaîne. C'est le smart contract Bitcoin le plus largement déployé aujourd'hui.

Les Hash Time-Locked Contracts (HTLC). Le mécanisme qui permet aux paiements Lightning de transiter par des intermédiaires sans leur faire confiance. Un paiement est verrouillé par un secret cryptographique. Le destinataire le déverrouille en révélant le secret. Les intermédiaires ne sont payés que lorsque le secret se propage en retour le long de la chaîne.

Les arbres de scripts Taproot (MAST). Taproot engage plusieurs conditions de dépense dans un arbre de hachage. Le dépensier ne révèle que la branche qu'il utilise réellement, gardant les conditions inutilisées privées. Les contrats complexes à chemins multiples ne divulguent presque rien des chemins que personne n'a empruntés.

Les coffres-forts à récupération différée. Une construction en deux transactions. La première transaction lance un processus de déverrouillage. Une seconde transaction, après un délai, le termine. Si la première transaction n'était pas autorisée, une clé de récupération peut intervenir pendant le délai. Le résultat se comporte comme un coffre-fort à verrou temporel.

Ces constructions tournent sur le réseau aujourd'hui. Ce ne sont pas des hypothèses de tableau blanc. Elles sont aussi bien plus simples que ce que l'environnement complet de smart contracts d'Ethereum peut exprimer.

Qu'est-ce que le mempool ?

Le mempool (memory pool, réserve en mémoire) contient les transactions valides et non confirmées qui attendent d'être incluses dans un bloc.

Une transaction Bitcoin que vous diffusez n'entre pas directement dans un bloc. Elle se propage à travers le réseau, nœud après nœud. Chaque nœud vérifie la signature, les entrées, le format. Si tout passe, le nœud ajoute la transaction à son mempool local. La transaction y reste, visible et non confirmée, jusqu'à ce qu'un mineur la prenne.

Les mineurs choisissent les transactions du mempool selon le taux de frais (satoshis par octet virtuel). Les taux de frais plus élevés passent devant dans la file. Quand le mempool est presque vide, même des transactions très bon marché se confirment vite. Quand il est plein, ce qui arrive lors des pics de demande, les transactions à frais bas peuvent attendre des heures ou des jours.

Chaque nœud plafonne la taille de son mempool. La valeur par défaut de Bitcoin Core est de 300 mégaoctets. Quand le mempool se remplit, le nœud écarte les transactions aux frais les plus bas pour libérer de la place. Les transactions écartées ne sont pas perdues pour toujours. Vous pouvez les rediffuser. Elles ne se confirmeront simplement pas tant que les frais ne baissent pas ou que vous n'augmentez pas les vôtres.

Replace-by-Fee (RBF). Bitcoin permet de remplacer une transaction non confirmée par une nouvelle version qui paie plus de frais, ce qui relève sa priorité. Les portefeuilles modernes le prennent en charge. Si votre transaction est bloquée, RBF est la solution standard.

Les transactions non confirmées expirent. Les nœuds Bitcoin Core écartent les transactions non confirmées de leur mempool après environ 14 jours. Les coins ne sont pas perdus. La transaction a juste besoin d'une nouvelle diffusion.

Conseils pratiques. Vérifiez les estimations de frais avant de diffuser. Des outils comme mempool.space affichent l'état du mempool en direct et les délais de confirmation estimés pour chaque niveau de frais. Pour les transactions non urgentes, les week-ends et les nuits en heure européenne tendent à être moins chers, parce que le volume mondial de transactions y baisse historiquement.

Définitions clés

UTXO. Unspent Transaction Output (sortie de transaction non dépensée). Les « pièces » individuelles qui composent un solde Bitcoin.

ScriptPubKey. Le script de verrouillage attaché à une sortie. Il définit qui peut la dépenser et comment.

ScriptSig / Witness. Les données de déverrouillage que le dépensier fournit pour satisfaire le script de verrouillage.

Verrou temporel (timelock). Une condition de Script qui bloque la dépense jusqu'à une date ou une hauteur de bloc donnée.

PSBT. Partially Signed Bitcoin Transaction (transaction Bitcoin partiellement signée). Un format standardisé pour partager et cosigner des transactions qui nécessitent plusieurs parties. Les configurations multisig et le trading d'Ordinals en dépendent.

P2TR (Pay-to-Taproot). Le format d'adresse Bitcoin recommandé aujourd'hui. Il utilise les signatures Schnorr et MAST pour des conditions de dépense complexes, efficaces et privées.

Mempool. La réserve de transactions valides mais non confirmées qui attendent les mineurs.

RBF (Replace-by-Fee). Un mécanisme qui permet à un expéditeur d'augmenter les frais d'une transaction non confirmée pour accélérer sa confirmation.

Note de risque

Bitcoin Script est puissant à l'intérieur de ses limites et impitoyable en dehors. Un script mal écrit peut verrouiller des coins dans une sortie que personne ne pourra jamais dépenser. Les constructions multisig et à verrou temporel exigent une planification et des tests soigneux, surtout pour la sauvegarde et la récupération. Les frais du mempool oscillent fortement avec la demande. Les transactions à très bas frais peuvent rester non confirmées pendant de longues périodes quand le réseau est chargé. N'utilisez que des logiciels que vous comprenez et en qui vous avez confiance pour tout travail de Script non standard.

Ce qu'il faut retenir

Bitcoin Script est simple et borné à dessein. C'est ce qui rend Bitcoin sûr, prévisible et digne de confiance à grande échelle. Le prix à payer, c'est que les applications complexes vivent sur des couches supérieures. Le mempool est la zone d'attente de chaque transaction. Lisez-le bien et vous fixerez vos frais intelligemment. Taproot et Schnorr sont la frontière actuelle de l'expressivité de Bitcoin, rendant les contrats complexes à la fois plus privés et moins chers.

Résumé du chapitre

  • Bitcoin Script est un langage à pile présent dans chaque transaction. Il définit qui peut dépenser une sortie et sous quelles conditions.
  • Les codes OP sont les commandes individuelles. OP_CHECKSIG vérifie les signatures. OP_CHECKLOCKTIMEVERIFY impose les verrous temporels. OP_IF permet des chemins de dépense conditionnels.
  • Bitcoin Script n'est pas Turing-complet, par conception. Pas de boucles, pas d'état persistant. La validation reste rapide, prévisible et sûre.
  • Bitcoin exprime de vrais smart contracts en usage actif aujourd'hui : multisig, verrous temporels, canaux de paiement Lightning, HTLC, arbres de scripts Taproot.
  • Le mempool contient les transactions non confirmées. Les mineurs priorisent selon le taux de frais. RBF permet aux expéditeurs d'augmenter les frais des transactions bloquées. La taille du mempool et les conditions de frais évoluent avec la demande.

Références

  • Antonopoulos, A. Mastering Bitcoin. O'Reilly
  • Bitcoin.org Developer Guides, référence Script
  • Bulletins Bitcoin Optech : documentation Taproot, Schnorr, MAST
  • Mempool.space : estimation des frais en direct et visualisation du mempool
  • Chaincode Labs : supports de formation sur Bitcoin Script
  • Documentation Bitcoin Core : politiques de mempool et RBF

Ce contenu est éducatif et ne constitue pas un conseil financier.