Le 9 novembre 2026 à 09 h 30 UTC, le bloc 975 157 a confirmé une transaction de 223 octets dont l’identifiant commence par 47b6082f. Elle dépense une sortie antérieure de 9 109 701 satoshis et en crée deux nouvelles, de 288 100 et 8 820 000 satoshis. Les 1 601 satoshis qui manquent sont allés au mineur sous forme de frais. Nulle part dans ces octets on ne trouve le solde d’un expéditeur ni le nom d’un destinataire. On y trouve deux petits verrous et une clé qui a ouvert un verrou plus ancien. Ces verrous sont écrits en script Bitcoin, le petit langage de programmation que chaque nœud complet exécute pour décider si une pièce peut bouger.
Dix-sept ans plus tôt, le 12 janvier 2009, le bloc 170 portait une transaction construite sur le même squelette : une entrée, deux sorties, un numéro de version et un temps de verrouillage. Elle envoyait 10 BTC vers un nouveau verrou et 40 BTC à son créateur. Hal Finney a écrit sur le forum Bitcointalk le 19 mars 2013 qu’blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il avait été le destinataire de la première transaction bitcoin (en anglais), dix pièces envoyées à titre d’essai par Satoshi Nakamoto, et le paiement de 10 BTC du bloc 170 est celui que l’on identifie d’ordinaire à cet essai. Le format a gagné des champs depuis, et l’opcode qui a jugé ce paiement, OP_CHECKSIG, fait toujours partie des règles que chaque nœud applique.
Chaque préfixe d’adresse qu’affiche un portefeuille, 1, 3, bc1q ou bc1p, désigne l’un des quelques verrous standard. Le multisig, les verrous temporels et les règles de relais des nœuds ne sont, au fond, que des règles sur la manière d’écrire et d’exécuter ces verrous, et on peut les lire directement dans les octets.
Une transaction bitcoin déplace des verrous, pas des soldes
Bitcoin ne tient aucun compte. Il tient un ensemble de sorties non dépensées, chacune étant un montant muni d’un verrou, et une transaction en détruit certaines pour en créer de nouvelles. Une sortie se dépense toujours en entier : un paiement produit donc le plus souvent de la monnaie rendue à l’expéditeur, et le solde d’un portefeuille n’est que la somme des sorties que ses clés savent ouvrir. La sélection des pièces, la poussière, la consolidation et les indices de confidentialité que laissent les sorties sont traités dans notre leçon sur les modèles UTXO et de compte ; ici, on les tient pour acquis.
Il en va de même des frais. Une transaction paie à la taille, comptée en unités de poids et en octets virtuels, à un tarif en satoshis par octet virtuel que l’expéditeur choisit et que les mineurs classent. Le fonctionnement de cette enchère, la façon dont le remplacement par les frais (RBF) et l’enfant qui paie pour le parent (CPFP) sauvent un paiement bloqué, et la raison pour laquelle les six confirmations sont devenues une habitude sont expliqués dans notre guide du mempool et des frais de transaction. D’où viennent ces octets, et ce que fait chacun d’eux, c’est une autre affaire.
Une idée du livre blanc encadre le reste. Satoshi Nakamoto écrit à la section 2 : « Nous définissons une pièce électronique comme une chaîne de signatures numériques » (traduction, texte original en anglais). Chaque sortie dit quelle signature elle attend, chaque entrée la fournit. Si les clés publiques et les signatures sont nouvelles pour vous, lisez d’abord le fonctionnement des clés privées et publiques, car tous les verrous ci-dessous se terminent par une vérification de signature.
Les octets d’une transaction bitcoin, champ par champ
Une transaction est une courte suite d’octets dans un ordre fixe. La référence pour développeurs de Bitcoin (en anglais) la documente champ par champ. Les compteurs et les longueurs utilisent un entier de taille variable appelé compactSize : un octet pour les valeurs jusqu’à 252, puis un octet marqueur (0xfd, 0xfe ou 0xff) suivi de 2, 4 ou 8 octets. Les nombres sont stockés en little-endian, l’octet de poids faible en premier, ce qui explique pourquoi les dumps hexadécimaux semblent brouillés à l’œil humain.
Sept champs, dont deux n’existent que dans les transactions SegWit
| Champ | Taille | Contenu |
|---|---|---|
| version | 4 octets | 1 ou 2 dans la plupart des transactions ; 2 active les verrous temporels relatifs (BIP 68). Bitcoin Core relaie les versions 1 à 3 |
| marqueur et drapeau | 2 octets (0x00 0x01) | Présents seulement quand la transaction porte des données de témoin (SegWit) |
| nombre d’entrées | compactSize | Nombre d’entrées |
| entrées | 36 octets + script + 4 octets chacune | Point de sortie (txid précédent et indice de sortie), scriptSig, séquence |
| nombre de sorties | compactSize | Nombre de sorties |
| sorties | 8 octets + script chacune | Valeur en satoshis et scriptPubKey (le verrou) |
| témoin (witness) | variable | Une pile d’éléments par entrée, SegWit uniquement |
| temps de verrouillage (lock time) | 4 octets | Hauteur de bloc ou heure la plus proche à laquelle la transaction devient valide |
Une entrée désigne une sortie antérieure et apporte la preuve
Une entrée n’indique pas combien elle dépense. Elle désigne une sortie antérieure par son point de sortie (outpoint) : l’identifiant de 32 octets de la transaction qui l’a créée, plus un indice de 4 octets de la sortie dans cette transaction. Le nœud cherche ce point de sortie dans son ensemble UTXO, y trouve le montant et le verrou, puis vérifie la preuve. C’est pourquoi une transaction ne peut pas être validée par quelqu’un qui ne connaît pas les pièces qu’elle dépense.
Le txid contenu dans un point de sortie est stocké dans l’ordre d’octets interne, l’inverse de celui qu’affichent les explorateurs de blocs. L’entrée de notre transaction du 9 novembre dépense une sortie de la transaction 403f3c54…f864, et pourtant l’hexadécimal brut commence ce champ par 64f81cf0. Ce sont les mêmes 32 octets lus dans des sens opposés.
Après le point de sortie vient le scriptSig, les données qui satisfont l’ancien verrou, précédé de sa longueur. Pour les anciens types d’adresse, il contient une signature et une clé publique ; pour les dépenses SegWit, il est vide et la preuve passe dans le témoin. L’entrée se termine par un numéro de séquence de 4 octets. Il remplit aujourd’hui trois fonctions : une valeur inférieure à 0xffffffff permet au temps de verrouillage de s’appliquer, 0xfffffffd est la valeur que les portefeuilles emploient pour signaler qu’ils acceptent une hausse des frais (BIP 125), et dans les transactions de version 2 il peut porter un verrou temporel relatif (BIP 68).
Une sortie, c’est un montant et un verrou
Une sortie n’a que deux parties : une valeur en satoshis sur 8 octets et un scriptPubKey, le script de verrouillage. La valeur peut être nulle, et c’est ainsi que fonctionnent les sorties de données. Le scriptPubKey décide de toute la propriété : celui qui peut produire des données faisant réussir ce script peut dépenser le montant, et rien d’autre dans le protocole n’enregistre à qui il appartient.
Une transaction par bloc fait exception. La transaction coinbase qui rémunère le mineur a une seule entrée, au point de sortie nul (32 octets à zéro et l’indice 0xffffffff), et un script libre de 100 octets au plus qui doit commencer par la hauteur du bloc depuis le BIP 34. Ses sorties réclament la subvention plus les frais, la subvention qui est divisée par deux tous les 210 000 blocs, comme l’explique notre leçon sur le halving du bitcoin et la subvention de bloc.
La transaction 47b6082f, lue octet par octet
Voici l’hexadécimal complet de la transaction du bloc 975 157 sur mempool.space (en anglais), découpé aux frontières des champs. Elle pèse 565 unités de poids et dépense une sortie SegWit native : le marqueur, le drapeau et le témoin sont donc présents.
02000000 version 2
00 01 marqueur et drapeau SegWit
01 1 entrée
64f81cf0...543c3f40 txid précédent (403f3c54...f864 inversé)
00000000 indice de sortie 0
00 longueur du scriptSig 0 (vide)
fdffffff séquence 0xfffffffd
02 2 sorties
6465040000000000 288 100 sat (0x046564)
16 0014 08696e26...a99d96 script de 22 octets : OP_0, push de 20 octets (P2WPKH)
2095860000000000 8 820 000 sat (0x869520)
17 a914 33972a6d...8e5177 87 script de 23 octets : OP_HASH160, push de 20, OP_EQUAL (P2SH)
02 témoin : 2 éléments pour l'entrée 0
47 3044...01 71 octets : signature DER + octet sighash 0x01
21 02e1b9f5...213edd 33 octets : clé publique compressée
33e10e00 temps de verrouillage 975 155 (0x0ee133)Lus dans l’ordre, ces octets racontent une petite histoire. Version 2. Une entrée, qui prend la sortie 0 d’une transaction antérieure, laquelle contenait selon l’explorateur 9 109 701 satoshis sous un verrou P2WPKH. Un scriptSig vide, puisque la preuve se trouve dans le témoin. Une séquence de 0xfffffffd, qui signale que l’expéditeur accepte une hausse des frais. Deux sorties : 288 100 satoshis vers une adresse bc1q et 8 820 000 satoshis vers une adresse qui commence par 3. Puis le témoin : une signature qui se termine par 0x01, le drapeau SIGHASH_ALL, et la clé publique dont le hachage correspond à l’ancien verrou. Enfin, un temps de verrouillage de 975 155.
Laquelle des sorties est le paiement, laquelle est la monnaie rendue ? Les octets ne le disent pas. Un explorateur ou un analyste de la chaîne ne peut que deviner, et il peut se tromper. Les sommes confirment seulement les frais : 9 109 701 moins 288 100 moins 8 820 000 laisse 1 601 satoshis, qu’aucune sortie ne réclame et que le mineur encaisse.
D’où viennent le txid, le poids et le tarif des frais
Le txid est le double hachage SHA-256 de la transaction sérialisée sans le marqueur, le drapeau et le témoin, affiché dans l’ordre d’octets inversé. Retirez ces champs de l’hexadécimal ci-dessus et il reste 114 octets ; leur double SHA-256, inversé, donne 47b6082f…d26a. Laisser le témoin hors de l’identifiant permet de changer une signature sans changer le txid, une propriété qu’a introduite SegWit.
Le poids compte les octets hors témoin quatre fois et les octets du témoin une fois : 114 × 3 + 223 = 565 unités de poids, soit 141,25 octets virtuels, que les explorateurs arrondissent à 142 vB. Les frais de 1 601 satoshis divisés par 141,25 donnent environ 11,3 satoshis par octet virtuel. C’était le tarif payé par cette transaction au moment où elle a été minée ; il ne dit rien du tarif à payer aujourd’hui, que mempool.space donnait à 1 à 2 sat/vB à la même heure.
Le script Bitcoin : un langage à pile sans boucle
Le script Bitcoin se lit de gauche à droite. Les éléments de données sont empilés ; les opcodes dépilent des éléments, les traitent et empilent des résultats. Il existe des conditions (OP_IF, OP_ELSE) mais ni boucle ni saut en arrière, de sorte que tout script se termine en un nombre d’étapes connu d’avance. La limite est voulue : un nœud doit pouvoir vérifier des milliers de scripts par bloc sans risquer de tomber sur un programme qui ne s’arrête jamais.
Le code source de Bitcoin Core fixe en plus des plafonds stricts. Un élément empilé peut contenir 520 octets au plus, un script 10 000 octets au plus, un script peut exécuter au maximum 201 opcodes qui ne sont pas des empilements, la pile peut contenir 1 000 éléments au plus, et OP_CHECKMULTISIG accepte 20 clés publiques au plus. Les opcodes arithmétiques travaillent sur des nombres de 4 octets au plus. Ces valeurs figurent dans le fichier script.h et dans l’interpréteur, et ce sont des règles de consensus : un bloc contenant un script qui les enfreint est invalide.
Dépenser une sortie P2PKH, un opcode à la fois
La dépense P2PKH la plus célèbre est peut-être celle du bloc 57 043. Le 18 mai 2010, un utilisateur du forum nommé laszlo a proposé 10 000 bitcoins contre deux grandes pizzas sur Bitcointalk, et le 22 mai il a annoncé que l’échange était fait (en anglais). La transaction confirmée ce jour-là à 18 h 16 UTC compte 131 entrées, toutes de type P2PKH, et une seule sortie de 10 000 BTC. Sa première entrée dépense une sortie de 150 BTC dont le verrou est le suivant :
OP_DUP OP_HASH160 <05bf3a3aea6335a3949c0a351ff3afcba884e125> OP_EQUALVERIFY OP_CHECKSIGLe scriptSig de l’entrée fait 140 octets : une signature de 73 octets et une clé publique non compressée de 65 octets, deux empilements et rien d’autre. Le nœud exécute d’abord le scriptSig, qui laisse ces deux éléments sur la pile, puis exécute le scriptPubKey sur cette pile. Le tableau montre la pile après chaque étape, le sommet de la pile étant à droite.
| Étape | Élément exécuté | Pile ensuite |
|---|---|---|
| 0 | le scriptSig empile ses deux éléments | sig, pubKey |
| 1 | OP_DUP copie l’élément du sommet | sig, pubKey, pubKey |
| 2 | OP_HASH160 le hache : RIPEMD-160 du SHA-256 | sig, pubKey, hash(pubKey) |
| 3 | empile les 20 octets 05bf3a3a…e125 pris dans le verrou | sig, pubKey, hash(pubKey), 05bf3a3a…e125 |
| 4 | OP_EQUALVERIFY compare les deux hachages et fait échouer le script s’ils diffèrent | sig, pubKey |
| 5 | OP_CHECKSIG vérifie sig par rapport à pubKey et à la transaction | true |
L’étape 4 est celle où une mauvaise clé s’arrête : une autre clé publique donne un autre hachage, et le script échoue avant qu’aucune signature ne soit vérifiée. L’étape 5 est celle où une mauvaise signature s’arrête. Seul celui qui détient la clé privée associée à cette clé publique peut signer cette transaction précise, donc seul lui peut produire des données qui laissent true sur la pile.
La transaction des pizzas montre aussi ce que ce format de script d’origine coûtait en place. 111 de ses 131 entrées étaient des sorties de 0,01 BTC chacune, et chacune portait son propre scriptSig de 138 à 140 octets, surtout une clé publique non compressée de 65 octets et une signature. Avec le point de sortie et la séquence, chaque entrée prenait environ 180 octets, et la transaction entière 23 620 octets pour une seule sortie. Une entrée SegWit native avec une clé compressée prend aujourd’hui environ 68 octets virtuels.
Pourquoi le verrou contient le hachage de la clé, pas la clé
Les toutes premières sorties, comme celles du bloc 170, placent la clé publique entière dans le verrou, suivie d’OP_CHECKSIG. Ce type, le paiement vers une clé publique, occupe 65 octets de clé publique dans chaque sortie, et n’importe qui voit la clé avant même qu’elle serve. Le paiement vers un hachage de clé publique l’a remplacé par un hachage de 20 octets. La sortie est plus courte, et la clé publique n’apparaît sur la chaîne qu’au moment où la pièce est dépensée.
Ce hachage de 20 octets est aussi ce qu’encode une adresse. Une adresse historique est ce hachage plus un octet de version et une somme de contrôle, écrits en Base58 pour qu’une faute de frappe soit détectée avant que l’argent ne parte. Notre leçon sur ce qu’est une adresse crypto montre l’encodage ; l’essentiel ici est qu’une adresse est une description compacte d’un scriptPubKey, pas un compte.
Les deux scripts s’exécutent l’un après l’autre, sans être collés
Dans la première version de Bitcoin, le nœud joignait le scriptSig et le scriptPubKey en un seul script et l’exécutait. Un scriptSig pouvait alors contenir des opcodes qui interféraient avec le verrou, et un correctif ultérieur a séparé l’exécution en deux. L’interpréteur de Bitcoin Core (en anglais) porte encore le commentaire selon lequel les deux scripts doivent être évalués l’un après l’autre sur la même pile et non concaténés, avec la référence CVE-2010-5141.
Le succès a un sens précis. Une fois les deux scripts exécutés, la pile ne doit pas être vide et son élément du sommet doit compter pour vrai. En Script, une chaîne d’octets est fausse quand elle est vide, composée uniquement d’octets à zéro, ou égale à zéro avec le bit de signe (zéro négatif) ; tout le reste est vrai. Si un opcode échoue en cours de route, par exemple un opcode VERIFY qui rencontre une valeur fausse, toute la dépense est invalide.
Quinze opcodes désactivés en août 2010
Le langage de script livré à l’origine par Satoshi était plus large. Un commit signé s_nakamoto le 15 août 2010, avec le message « misc changes », a ajouté un contrôle qui fait échouer tout script contenant OP_CAT, OP_SUBSTR, OP_LEFT, OP_RIGHT, OP_INVERT, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT ou OP_RSHIFT. Le même commit a ramené l’élément empilé maximal de 5 000 à 520 octets et les opérandes numériques de 258 à 4 octets. Le message du commit n’en donne aucune raison ; le Bitcoin Core d’aujourd’hui étiquette ce contrôle « Disabled opcodes (CVE-2010-5137) », en référence à un bogue de cette famille d’opcodes.
« Désactivé » est un mot faible. Même à l’intérieur d’une branche d’OP_IF qui ne s’exécute jamais, l’un de ces opcodes fait échouer le script. Le retour d’OP_CAT fait l’objet d’une proposition toujours d’actualité, le BIP 347, l’un des débats de notre prochaine leçon sur la gouvernance de Bitcoin et les BIP.
Cinq types de sorties, quatre préfixes d’adresse
Les portefeuilles n’inventent pas leurs verrous. Ils emploient un petit ensemble de modèles standard, chacun avec son format d’adresse. Connaître le modèle derrière une adresse indique ce que le dépensier devra révéler et à peu près combien d’octets cela coûtera.
P2PK et P2PKH : les verrous de 2009
Le paiement vers une clé publique (P2PK) est le verrou du bloc 170 : une clé publique et OP_CHECKSIG ; pour le dépenser, le scriptSig ne contient qu’une signature. Il n’a pas de format d’adresse propre. Le paiement vers un hachage de clé publique (P2PKH) est le verrou à cinq opcodes exécuté dans le tableau plus haut. Ses adresses commencent par 1 sur le réseau principal, comme l’adresse 1XPTgDRh… derrière l’entrée de la pizza.
P2SH : le verrou qui ne contient que le hachage d’un script
Le BIP 16 (en anglais), écrit par Gavin Andresen et appliqué aux blocs à partir du 1er avril 2012, a introduit le paiement vers un hachage de script. Le scriptPubKey est OP_HASH160, un hachage de 20 octets et OP_EQUAL. Le dépensier révèle le script complet, le redeemScript, comme dernier élément empilé du scriptSig, avec les données dont il a besoin. Un nœud vérifie d’abord que le redeemScript a bien pour hachage la valeur du verrou, puis exécute le redeemScript lui-même sur la pile restante.
Le P2SH a déplacé le coût et la complexité du payeur vers le dépensier. Celui qui paie un portefeuille multisig 2-sur-3 envoie vers une courte adresse qui commence par 3, comme le fait la sortie de 8 820 000 satoshis de notre transaction du 9 novembre, et ne voit jamais les clés. Le redeemScript est un élément empilé, donc la limite de 520 octets s’y applique : 15 clés publiques compressées au plus dans un multisig. Le BIP 16 était un soft fork, un changement de règles que les anciens nœuds acceptent encore, comme l’explique notre leçon sur les soft forks et les hard forks.
Les sorties SegWit et Taproot, en deux lignes
SegWit en version 0, activé en août 2017, a ajouté le P2WPKH (OP_0 plus un hachage de clé de 20 octets) et le P2WSH (OP_0 plus un hachage de script de 32 octets), avec des adresses qui commencent par bc1q ; la preuve passe dans le témoin. Taproot, activé en 2021, a ajouté le P2TR (OP_1 plus une clé de 32 octets), avec des adresses qui commencent par bc1p. Le fonctionnement du témoin, du poids, des signatures de Schnorr et des arbres de scripts fait l’objet de la prochaine leçon de ce parcours, SegWit et Taproot.
OP_RETURN, multisig nu et ancres
Trois autres sortes de sorties reviennent dans chaque bloc. Une sortie OP_RETURN commence par un opcode qui échoue aussitôt : elle ne peut donc jamais être dépensée ; elle porte des données, en général avec une valeur nulle, et les nœuds ne la gardent pas dans l’ensemble UTXO. Le multisig nu place le script m-sur-n complet dans la sortie, sans hachage. Et les explorateurs affichent désormais une toute petite sortie étiquetée ancre (pay-to-anchor) : le script de quatre octets OP_1 suivi des deux octets 0x4e73, que Bitcoin Core reconnaît à ce motif exact et qui se dépense avec un témoin vide, sans aucune signature. Elle existe pour qu’une transaction enfant puisse ajouter des frais plus tard.
Les types de sorties dans neuf blocs du 9 novembre 2026 : un petit échantillon
Il n’existe aucun décompte officiel unique des types de sorties, et les graphiques de longue date de transactionfee.info vivent désormais sur mainnet.observer sous forme de visuels interactifs. Coindaro a donc fait son propre décompte : il a lu les blocs bruts 975 149 à 975 157 sur mempool.space le 9 novembre 2026 et classé chaque sortie selon son modèle de script. C’est un petit échantillon, neuf blocs dont les horodatages d’en-tête vont de 08 h 30 à 09 h 33 UTC ce matin-là, et ses deux moitiés se contredisent déjà, ce qui est tout l’intérêt du tableau.
| Type de sortie | Préfixe d’adresse | Blocs 975 149-975 154 (42 379 sorties) | Blocs 975 155-975 157 (40 551 sorties) | Les neuf blocs (82 930 sorties) |
|---|---|---|---|---|
| P2WPKH | bc1q | 60,3 % | 46,6 % | 53,6 % |
| OP_RETURN (données) | aucun | 18,9 % | 40,2 % | 29,3 % |
| P2TR | bc1p | 8,2 % | 3,2 % | 5,8 % |
| P2SH | 3 | 5,7 % | 1,9 % | 3,8 % |
| P2PKH | 1 | 5,4 % | 1,9 % | 3,7 % |
| P2WSH | bc1q (plus longue) | 1,6 % | 0,5 % | 1,0 % |
| Pay-to-anchor | aucun | 0,0 % | 5,7 % | 2,8 % |
Source : décompte de Coindaro des 82 930 sorties créées dans les blocs 975 149 à 975 157 (37 675 transactions), blocs bruts de mempool.space, 9 novembre 2026. Un échantillon de neuf blocs, environ une heure de chaîne, pas une tendance. Aucune sortie P2PK ni multisig nue n’y figurait.
Les clés SegWit natives dominent les deux moitiés. Le reste oscille : les sorties de données représentaient 19 % des sorties dans les six premiers blocs et 40 % dans les trois suivants, et les ancres sont passées de zéro à 2 323, toutes dans le bloc 975 155. Le bloc 975 157 à lui seul contenait 7 941 sorties de données parmi ses 15 923 sorties, soit près d’une pour chacune de ses 7 959 transactions. Quelques gros lots de transactions porteuses de données ou d’ancres suffisent à déplacer de plusieurs dizaines de points la part sur trois blocs : lisez donc tout instantané d’un jour sur les types de sorties comme la météo, pas comme le climat. En laissant de côté les sorties de données, le P2WPKH représentait encore environ les trois quarts des sorties dépensables créées dans chaque moitié (74,3 % et 77,9 %).
Ce que signe une signature : les drapeaux sighash
OP_CHECKSIG ne vérifie pas une signature par rapport à la transaction entière telle qu’elle circule. Il la vérifie par rapport à un condensé construit à partir d’une copie modifiée de la transaction, et le dernier octet de la signature, le drapeau sighash, dit quelles parties sont entrées dans cette copie. Le guide du développeur Bitcoin (en anglais) liste les options. Toutes signent le temps de verrouillage.
| Drapeau (octet) | Ce que s’engage à signer le signataire | Ce que les autres peuvent encore changer |
|---|---|---|
| SIGHASH_ALL (0x01) | Toutes les entrées et toutes les sorties | Rien, sauf les scripts de signature des autres entrées |
| SIGHASH_NONE (0x02) | Toutes les entrées, aucune sortie | La destination des fonds, sauf si une autre signature protège les sorties |
| SIGHASH_SINGLE (0x03) | Toutes les entrées et la sortie de même indice | Toutes les autres sorties |
| ALL | ANYONECANPAY (0x81) | Cette entrée et toutes les sorties | Les autres entrées peuvent être ajoutées ou retirées |
| NONE | ANYONECANPAY (0x82) | Cette entrée seulement | Tout le reste |
| SINGLE | ANYONECANPAY (0x83) | Cette entrée et la sortie correspondante | Les autres entrées et sorties |
Presque tous les paiements de portefeuille emploient SIGHASH_ALL ; notre transaction de 2026 comme l’entrée de la pizza terminent leurs signatures par 0x01. Les autres drapeaux existent pour la coopération entre des personnes qui ne se font pas confiance. Avec ALL | ANYONECANPAY, par exemple, un groupe peut financer une seule sortie, chaque contributeur ne signant que sa propre entrée et la cible fixée, et la transaction ne devient valide que lorsque les entrées atteignent le total.
SIGHASH_SINGLE cache un vieux piège. Si un signataire l’emploie sur une entrée dont l’indice n’a pas de sortie correspondante, le code d’origine signe la valeur 1 au lieu d’un vrai condensé, ce que le guide du développeur décrit comme une brèche dans le schéma de sécurité : une signature produite ainsi peut être réutilisée. Les portefeuilles évitent complètement ce cas.
Les signatures elles-mêmes sont des ECDSA encodées en DER dans les scripts historiques et SegWit v0, de 71 ou 72 octets avec le drapeau en général. Le BIP 66, appliqué depuis le bloc 363 725 en juillet 2015, a fait de l’encodage DER strict une règle de consensus. Même ainsi, un tiers pouvait transformer une signature valide en une autre signature valide et donc changer le txid d’une transaction non confirmée, un problème appelé malléabilité. SegWit l’a supprimé en sortant les signatures du txid, comme l’explique la prochaine leçon.
Multisig et l’élément en trop que mange OP_CHECKMULTISIG
Un verrou multisig exige m signatures parmi n clés publiques. Le script est un nombre m, les n clés, le nombre n et OP_CHECKMULTISIG, m et n s’écrivant avec les opcodes OP_1 à OP_16. Un verrou 2-sur-3 ressemble à ceci :
OP_2 <pubKeyA> <pubKeyB> <pubKeyC> OP_3 OP_CHECKMULTISIG
scriptSig: OP_0 <sigA> <sigC>L’opcode dépile n, les clés, m et les signatures, puis parcourt les deux listes. Les signatures doivent venir dans le même ordre que leurs clés, car le code avance dans les clés sans jamais revenir en arrière. Ensuite, il dépile un élément de plus. L’interpréteur de Bitcoin Core le dit sans détour : « A bug causes CHECKMULTISIG to consume one extra argument whose contents were not checked in any way » (un bogue fait que CHECKMULTISIG consomme un argument de plus dont le contenu n’est vérifié en aucune façon, traduction libre). Supprimer ce dépilement en trop changerait l’évaluation de scripts déjà présents sur la chaîne, donc le bogue est resté, et chaque dépense multisig commence son scriptSig par un OP_0 jetable pour l’alimenter.
Comme cet élément en trop n’était jamais vérifié, quiconque relayait une dépense multisig pouvait remplacer l’OP_0 par une autre valeur et changer l’identifiant de la transaction sans l’invalider. Le BIP 147 (en anglais) a fermé cette brèche avec la règle NULLDUMMY : l’élément factice doit être un tableau d’octets vide. Bitcoin Core l’appliquait comme règle de relais depuis la version 0.10.0, et elle est devenue une règle de consensus avec le déploiement de SegWit en 2017.
Le multisig est la façon dont des entreprises, des fonds et des particuliers prudents répartissent le contrôle d’un stockage à froid sur plusieurs appareils ou plusieurs personnes, et la façon dont un séquestre fonctionne sans que personne ne détienne les pièces ; notre entrée de glossaire sur les portefeuilles multisig traite l’aspect pratique. En pratique, presque personne n’utilise plus de sorties multisig nues. La politique de relais de Bitcoin Core accepte le multisig nu avec 3 clés au plus, et l’enveloppe P2SH ou P2WSH garde le long script hors de la sortie jusqu’à la dépense. Sous P2SH, la limite standard de 1 650 octets pour le scriptSig suffit, selon le guide du développeur, pour un multisig 15-sur-15 à clés compressées.
Timelocks : des pièces qui ne bougent pas avant une date
Bitcoin dispose de quatre outils de verrouillage temporel. Deux se trouvent dans la transaction elle-même et disent quand la transaction devient valide ; deux sont des opcodes à l’intérieur d’un verrou et disent quand une sortie peut être dépensée. Deux sont absolus (une hauteur de bloc ou une date), deux sont relatifs (un délai compté à partir du moment où la pièce a été créée).
nLockTime et la parade contre le fee sniping dans notre transaction
Le temps de verrouillage de 4 octets à la fin de chaque transaction se lit comme une hauteur de bloc quand il est inférieur à 500 000 000, et comme un horodatage Unix sinon. Une transaction dont le temps de verrouillage est dans le futur ne peut pas encore entrer dans un bloc. La règle comporte un piège datant de 2009 : elle ne s’applique que si au moins une entrée a un numéro de séquence inférieur à 0xffffffff, ce qui explique que les portefeuilles qui fixent un temps de verrouillage abaissent aussi la séquence.
Notre transaction du 9 novembre porte le temps de verrouillage 975 155, et mempool.space la montre confirmée dans le bloc 975 157. On ignore quel portefeuille l’a construite, mais le motif correspond à une habitude connue appelée anti-fee-sniping, que suit entre autres le portefeuille de Bitcoin Core. Le code source de Core fixe le temps de verrouillage à la hauteur de la pointe actuelle de la chaîne, si bien que la transaction ne peut entrer que dans le bloc suivant ou dans un bloc ultérieur. Le but est de décourager le fee sniping, une attaque où un gros mineur re-mine le dernier bloc pour en saisir les frais : une transaction qui ne peut pas être placée à une hauteur antérieure laisse moins à prendre à un tel mineur. Dans environ un cas sur dix, Core choisit au hasard une hauteur jusqu’à 100 blocs plus ancienne, pour que les transactions diffusées un certain temps après leur signature, comme certaines transactions CoinJoin, se fondent dans la masse.
OP_CHECKLOCKTIMEVERIFY : un verrou muni d’une date
nLockTime ne retarde qu’une transaction que quelqu’un a déjà signée, et le signataire peut toujours en signer une autre sans ce délai. Le BIP 65 (en anglais), de Peter Todd, met la date dans la sortie. OP_CHECKLOCKTIMEVERIFY compare un nombre du script avec le nLockTime de la transaction qui dépense, et échoue sauf si le temps de verrouillage est du même type et au moins aussi grand, avec une séquence d’entrée inférieure à 0xffffffff. Puisque la transaction ne peut pas être minée avant son temps de verrouillage, la pièce ne peut pas bouger avant la date inscrite dans le script. Le BIP 65 a redéfini un opcode sans effet, OP_NOP2, c’était donc un soft fork ; Bitcoin Core consigne son activation au bloc 388 381, miné le 14 décembre 2015.
<expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIGLes verrous relatifs : nSequence et OP_CHECKSEQUENCEVERIFY
Le BIP 68 a donné au champ de séquence une seconde vie dans les transactions de version 2 ou plus. Quand le bit 31 n’est pas activé, les 16 bits de poids faible contiennent un délai qui doit s’écouler entre la confirmation de la sortie dépensée et la transaction qui la dépense. Le bit 22 choisit l’unité : des blocs, ou des unités de 512 secondes. Le maximum est de 65 535 blocs, soit environ 455 jours à dix minutes par bloc, ou 65 535 × 512 secondes, soit environ 388 jours.
Le BIP 112 (en anglais) a ajouté l’opcode correspondant, OP_CHECKSEQUENCEVERIFY, à la place d’OP_NOP3, pour qu’une sortie puisse exiger un tel délai. Les deux ont été déployés avec le BIP 113, qui mesure le temps par l’horodatage médian des blocs récents, et Bitcoin Core consigne leur activation au bloc 419 328, miné à 23 h 16 UTC le 4 juillet 2016. Un verrou relatif est ce dont les canaux de paiement ont besoin : une partie peut fermer un canal seule, mais doit attendre un nombre fixe de blocs avant de toucher sa part, ce qui laisse à l’autre le temps de réagir. Le Lightning Network, sujet d’une prochaine leçon de ce parcours, repose sur ce délai.
| Outil | Où il se trouve | Absolu ou relatif | Introduit |
|---|---|---|---|
| nLockTime | Champ de la transaction | Absolu (hauteur ou heure) | 2009, code d’origine |
| OP_CHECKLOCKTIMEVERIFY | Script de sortie | Absolu | BIP 65, bloc 388 381, 14 déc. 2015 |
| Verrou nSequence | Champ d’entrée (version 2+) | Relatif (blocs ou unités de 512 secondes) | BIP 68, bloc 419 328, 4 juil. 2016 |
| OP_CHECKSEQUENCEVERIFY | Script de sortie | Relatif | BIP 112, bloc 419 328, 4 juil. 2016 |
Les plans de succession emploient les mêmes outils de façon plus lente : un portefeuille peut verrouiller des pièces sur la clé de son propriétaire aujourd’hui et ajouter un second chemin qui ne s’ouvre à la clé d’un proche qu’après un an sans mouvement. Peu de portefeuilles grand public exposent ces options, mais les opcodes qui les permettent font partie du consensus depuis 2015 et 2016.
Règles de consensus et standardité
Tout ce qui précède et qui rend un bloc invalide relève du consensus : les limites de script, les opcodes désactivés, NULLDUMMY depuis 2017, les règles de verrouillage temporel. Les nœuds appliquent une seconde couche, plus stricte, aux transactions qu’ils n’ont pas encore vues dans un bloc, appelée standardité ou politique de relais. Une transaction non standard n’est pas invalide : les nœuds aux réglages par défaut refusent simplement de la transmettre. La leçon sur le mempool citée plus haut explique les limites de politique sur la taille, la poussière et le tarif (400 000 unités de poids, poussière calculée à 3 sat/vB, frais de relais minimum de 0,1 sat/vB dans le Bitcoin Core actuel). Ce qui compte ici, c’est la politique propre aux scripts.
| Politique de Bitcoin Core (policy.h, branche master, 9 nov. 2026) | Valeur | Limite de consensus, pour comparaison |
|---|---|---|
| scriptSig standard maximal | 1 650 octets | script de 10 000 octets |
| Multisig nu relayé | Jusqu’à 3 clés | Jusqu’à 20 clés |
| Opérations de signature dans un redeemScript P2SH | 15 | Aucune limite propre |
| Script de témoin P2WSH maximal | 3 600 octets | 10 000 octets |
| Versions de transaction relayées | 1 à 3 | Toutes |
| Taille minimale hors témoin | 65 octets | Aucune |
Au-delà des chiffres, la politique n’accepte que les modèles de sorties connus listés plus haut et exige des scriptSig qui ne font qu’empiler des données. Un script construit à partir d’une combinaison inhabituelle d’opcodes peut être parfaitement valide, mais il ne circulera que si un mineur le reçoit directement et choisit de l’inclure. Une fois dans un bloc, tous les nœuds l’acceptent, car les blocs ne sont jugés que par le consensus.
La politique peut changer dans une nouvelle version du logiciel sans fork ; le consensus ne peut pas changer sans soft fork ou hard fork, avec la coordination décrite dans la leçon sur les forks. La limite plus large des données OP_RETURN qu’a apportée Bitcoin Core 30.0 en octobre 2025, décrite dans la leçon sur le mempool, était un tel changement de politique (la documentation écrite avant elle parle encore de 80 octets) ; la dispute qui l’entoure relève de la prochaine leçon sur la gouvernance de Bitcoin.
Lire une transaction bitcoin dans un explorateur
Avec ces pièces en main, une page d’explorateur se lit autrement. L’onglet des entrées liste les points de sortie et, pour chacun, le type de verrou qui a été ouvert ; l’onglet des sorties liste les nouveaux verrous. Une entrée de type P2PKH montre une signature et une clé publique complète, une entrée P2WPKH montre les deux mêmes éléments dans le témoin, et une entrée P2TR par la voie de la clé montre une seule signature de 64 ou 65 octets. Notre guide pour lire un explorateur de blocs passe en revue les écrans.
Deux réflexes en découlent. Vérifiez le temps de verrouillage et les numéros de séquence quand un paiement semble bloqué : un temps de verrouillage dans le futur, ou une séquence finale sur une transaction qui compte sur lui, explique un retard qu’aucun frais ne corrigera. Et rappelez-vous que le réseau voit des scripts, pas des personnes : un explorateur ne peut pas dire si une sortie va vers un commerçant ou revient à l’expéditeur comme monnaie rendue.
Ce dernier point compte au moment de déclarer ses impôts. En France, la page de l’administration fiscale du 17 juillet 2026 indique un prélèvement forfaitaire unique (PFU) de 31,4 % sur les plus-values de 2026, et notre guide sur les impôts crypto en France en donne le cadre. La chaîne ne peut pas montrer qui contrôle une sortie : la preuve de ce qui est à vous reste à conserver par vous, c’est-à-dire le txid, la date et une note indiquant quelles sorties vous appartenaient.
La prochaine leçon de ce parcours reprend là où s’est arrêté le tableau des sorties : comment SegWit a déplacé les signatures dans le témoin et pourquoi Taproot a fait ressembler un multisig à un paiement à clé unique.
