Le bloc 481 824, horodaté 01:57:37 UTC le 24 août 2017, contient 1 866 transactions pour 989 323 octets et pèse 3 954 880 unités : 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 tient à la fois sous l’ancien plafond de 1 Mo et sous le nouveau, fixé à 4 millions d’unités, avec seulement 800 octets environ de données témoins. Le bloc 709 632, horodaté 05:15:27 UTC le 14 novembre 2021, mesure 1 410 904 octets, bien au-delà de 1 Mo, et pourtant il ne pèse que 3 881 749 unités, parce qu’environ 587 000 de ses octets sont des données témoins. Le premier a ouvert SegWit, le second Taproot. L’écart entre leurs tailles est le chemin le plus court pour comprendre SegWit et Taproot : ce que chaque mise à niveau a changé, et pourquoi la seconde avait besoin de la première.
Ce sont deux « soft forks » du format des transactions de Bitcoin, et tous deux sont entrés par la même porte. La version 0 du témoin, c’est SegWit (« Segregated Witness », littéralement « témoin séparé ») : elle a sorti les signatures de l’identifiant de la transaction et introduit le poids. La version 1, c’est Taproot : signatures de Schnorr, arbre de scripts de dépense cachés, et une dépense qui a le même aspect qu’une seule clé ou qu’un comité entier se tienne derrière. Sur les 144 blocs minés jusqu’à 09:30 UTC le 9 novembre 2026, 89,9 % des transactions contenaient des données témoins, d’après le décompte de Coindaro sur les blocs bruts détaillé plus bas.
Cette leçon suit la précédente du parcours, le fonctionnement des transactions et des scripts Bitcoin, qui démonte une transaction octet par octet, exécute un script P2PKH opcode par opcode et dresse la liste des types de sorties avec le préfixe de leurs adresses. Ces mécanismes sont supposés connus. Ce qui suit raconte ce qui a changé en 2017 et en 2021, et ce que cela a coûté.
SegWit et Taproot : deux mises à niveau par la même porte
Un soft fork durcit les règles de façon que les blocs produits par les mineurs à jour restent valides pour les nœuds qui n’ont jamais été mis à jour. Notre guide des soft forks et des hard forks explique la différence, la manière dont les mineurs signalent leur accord avec un bit de version, et la saga SegWit de 2017, du vote bloqué sous les 95 % et de l’échéance BIP 148 du 1er août jusqu’à la fenêtre plus courte de Speedy Trial pour Taproot en 2021. Un seul détail de cette mécanique compte ici : l’astuce qui a rendu possibles les deux mises à niveau.
SegWit a défini un nouveau type de sortie, le programme témoin : un petit nombre de 0 à 16 (la version) suivi de 2 à 40 octets de données. Pour un nœud qui tourne sous un logiciel d’avant 2017, une telle sortie est un script qui empile deux éléments et laisse une valeur non nulle sur la pile : n’importe qui peut donc la dépenser avec une preuve vide. Pour un nœud à jour, le numéro de version choisit un jeu de règles, et la preuve doit se trouver à un nouvel endroit, le témoin. Le BIP 141 le dit sans détour : les nœuds non mis à jour « considéreront tous les programmes témoin comme des scripts que n’importe qui peut dépenser » (traduction). Les anciens nœuds ne voient jamais une pièce volée, parce que les mineurs qui appliquent les nouvelles règles ne placent jamais un tel vol dans un bloc.
La version 0 a servi à SegWit en 2017. La version 1 était restée indéfinie, donc dépensable par n’importe qui, jusqu’à ce que Taproot lui donne des règles en 2021. Le BIP 341 reprend l’argument presque mot pour mot : les nœuds non mis à jour « considéreront tous les programmes témoin SegWit de version 1 comme des scripts que n’importe qui peut dépenser » (traduction). Les versions 2 à 16 sont toujours libres aujourd’hui, et c’est par elles qu’arriverait tout changement futur du même genre.
De la proposition à la règle active, bloc par bloc
Un élément de la route de 2017 manque à la plupart des récits courts. Le BIP 91, une règle appliquée par les mineurs avec un seuil de 269 blocs sur 336 (80 %), a été écrit comme moyen d’activer le déploiement existant « avec une majorité de puissance de calcul inférieure à 95 % » (traduction) : une fois actif, à partir du bloc 477 120, il rejetait tout bloc qui ne signalait pas SegWit. Les hauteurs ci-dessous ont été vérifiées sur mempool.space ; les heures sont des horodatages de blocs, qui peuvent s’écarter de l’heure réelle d’une heure ou plus.
| Date (horodatage du bloc, UTC) | Bloc | Événement |
|---|---|---|
| 21 déc. 2015 | Le BIP 141 (Segregated Witness) reçoit son numéro | |
| 27 oct. 2016 | Bitcoin Core 0.13.1 publié avec le code de déploiement de SegWit | |
| 15 nov. 2016 | Ouverture du signalement BIP 9 pour « segwit » (bit 1) | |
| 21 juil. 2017 | 476 784 | Verrouillage du BIP 91 pour la période de 336 blocs qui commence ici |
| 23 juil. 2017 | 477 120 | BIP 91 actif : les blocs qui ne signalent pas SegWit sont rejetés |
| 9 août 2017, 12:36 | 479 808 | Premier bloc de la période où SegWit est verrouillé |
| 24 août 2017, 01:57 | 481 824 | SegWit actif, exactement 2 016 blocs plus tard |
| 24 avr. 2021 | Ouverture de la fenêtre de signalement de Taproot (bit 2, 1 815 blocs sur 2 016) | |
| 13 juin 2021, 20:06 | 687 455 | Dernier bloc de la période où le seuil de 90 % a été franchi |
| 13 juin 2021, 20:07 | 687 456 | Taproot verrouillé, activation fixée au bloc 709 632 |
| 14 nov. 2021, 05:15 | 709 632 | Taproot actif (hauteur minimale d’activation du BIP 341) |
L’accord de New York et la comparaison des méthodes d’activation relèvent d’une leçon ultérieure du parcours, consacrée à la gouvernance de Bitcoin. Le reste de celle-ci traite de ce que font les règles.
Le problème que SegWit a réglé : un identifiant de transaction modifiable par des tiers
Un txid est le double hachage SHA-256 des octets de la transaction. Avant 2017, ces octets incluaient les signatures, et une signature pouvait être réécrite sans être brisée. ECDSA a une symétrie interne : si (r, s) est une signature valide, (r, n – s) l’est aussi, n étant l’ordre de la courbe. Le BIP 340 qualifie pour cette raison les signatures ECDSA de « malléables par nature » (traduction). Quiconque relayait une transaction non confirmée pouvait inverser s, ou ajouter un empilement inoffensif au scriptSig, et diffuser une version avec un autre txid qui dépensait les mêmes pièces vers les mêmes destinataires.
Pour un simple paiement, c’était une gêne : l’argent arrivait, sous un identifiant que l’expéditeur n’attendait pas. Pour tout ce qui reposait sur une transaction non confirmée, c’était fatal. Une seconde transaction qui dépense une sortie de la première la désigne par son txid. Si la première est minée sous un autre identifiant, la seconde pointe vers le vide et ne pourra jamais être confirmée. Les contrats qui exigent qu’une transaction de remboursement soit signée avant la diffusion de la transaction de financement, la base des canaux de paiement, ne pouvaient pas être construits sur un tel terrain.
Les développeurs ont tenté de boucher les trous un à un. Le BIP 66 a rendu l’encodage DER strict obligatoire par consensus en 2015, le BIP 147 a corrigé l’élément factice d’OP_CHECKMULTISIG, et le BIP 62, une liste plus large de règles contre la malléabilité, a fini avec le statut Closed. Chaque rustine couvrait un vecteur ; aucune ne couvrait un signataire qui re-signe volontairement. SegWit a pris une autre route. Son texte en énonce le résultat en une phrase :
« SegWit corrige le problème de la malléabilité des transactions de manière fondamentale, ce qui permet de construire sans confiance des chaînes de transactions dépendantes non confirmées. » (traduction) BIP 141
La méthode consiste à laisser les signatures hors du hachage qui nomme la transaction. Dans une dépense SegWit, le scriptSig est vide, la preuve se trouve dans le témoin, et le txid est calculé sur une sérialisation sans témoin. Modifier une signature ne change plus l’identifiant vers lequel pointent les autres transactions. Les notes de version de Bitcoin Core 0.13.1, du 27 octobre 2016, décrivent cela comme la solution de « tous les cas connus de malléabilité indésirable des transactions » (traduction). Les entrées legacy sont restées aussi malléables qu’avant, ce qui explique qu’une transaction qui les mélange à des entrées SegWit ne puisse pas compter sur la stabilité de son identifiant.
Ce que SegWit a changé à l’intérieur d’une transaction
Un témoin par entrée, et un second identifiant pour l’ensemble
La leçon 1 a montré l’octet marqueur 0x00 et l’octet drapeau 0x01 qui ouvrent une transaction SegWit, et les piles de témoins placées après ses sorties. Le BIP 144 définit cette sérialisation et la règle sur laquelle comptent les anciens nœuds : on ne leur envoie jamais cette forme, seulement la transaction dépouillée du marqueur, du drapeau et du témoin, qui est exactement la forme dont le hachage donne le txid. La forme complète a son propre hachage, le wtxid.
Le témoin doit toutefois rester lié au bloc, faute de quoi un mineur pourrait l’échanger. Le BIP 141 y pourvoit par la transaction coinbase : les wtxid de toutes les transactions alimentent un second arbre de Merkle, dont la racine est inscrite dans une sortie de la coinbase dont le script commence par les octets 0x6a24aa21a9ed, un OP_RETURN suivi de l’en-tête aa21a9ed. Un explorateur de blocs montre cette sortie dans tout bloc qui contient des transactions SegWit, ce qui, depuis 2017, veut dire presque tous. Les anciens nœuds la lisent comme une sortie de données ordinaire.
Le poids : la limite de 4 millions d’unités qui a remplacé 1 Mo
Sortir les signatures de l’ancienne sérialisation les a aussi sorties de l’ancien décompte de taille, et le BIP 141 a remplacé la limite de 1 Mo par une limite de poids. Le poids d’une transaction est sa taille de base (sans témoin) multipliée par trois, plus sa taille totale ; un bloc peut peser au plus 4 000 000 d’unités. Les octets hors témoin comptent quatre unités chacun, les octets de témoin une seule. La taille virtuelle est le poids divisé par quatre, arrondi au supérieur, et c’est à elle que s’appliquent les taux de frais en sat/vB. Notre guide du mempool et des frais de transaction montre comment les portefeuilles s’appuient sur les vbytes pour fixer des frais ; la leçon 1 déroule la formule sur une vraie transaction de 565 unités.
Les deux blocs de l’ouverture montrent la règle à l’œuvre. Dans le bloc 481 824, la taille de base et la taille totale sont presque égales : c’est un bloc classique de 1 Mo qui respecte aussi la nouvelle règle. Dans le bloc 709 632, environ 587 000 octets sont du témoin et environ 824 000 des données de base : trois fois la base plus le total donne 3 881 749. Un bloc ne peut approcher 4 Mo que s’il est presque entièrement composé de témoin, ce que ne sont pas les paiements ordinaires. Dans les notes de la version 0.13.1, Bitcoin Core estimait que le réseau pourrait traiter « environ 70 % de transactions en plus » (traduction) si tous les portefeuilles passaient à SegWit, une projection tirée du contenu des blocs de 2016 et non un résultat mesuré.
Parmi les bénéfices de sa conception, le BIP 141 range cette remise et la décrit comme une augmentation de la taille des blocs « dans une certaine mesure » (traduction). Savoir si c’était une réponse honnête à la demande de blocs plus gros est le vieux différend ; la règle elle-même n’a pas changé depuis 2017.
Un nouveau hachage de signature qui contient le montant
Le BIP 143 a changé ce que s’engage à signer une signature SegWit, et il a réglé deux anciens problèmes au passage. Dans les scripts legacy, chaque vérification de signature rehache l’essentiel de la transaction, si bien que le travail de hachage croît avec le carré du nombre d’opérations de signature. Le BIP 143 donne le pire cas : « une transaction de 1 Mo avec 5569 sigops peut demander 25 secondes de vérification » (traduction), contre environ 2 secondes pour un bloc normal de 1 Mo sur un ordinateur de 2015. Le nouvel algorithme hache une seule fois les parties communes et les réutilise : le coût croît désormais de façon linéaire.
Le second correctif concerne les portefeuilles matériels. Une signature legacy ne s’engage pas sur le montant de la pièce dépensée : un appareil hors ligne devait donc recevoir la transaction précédente complète pour savoir ce qu’il signait, et quels frais. Avec le BIP 143, chaque signature s’engage sur le montant de son entrée. Si l’on ment à l’appareil sur ce montant, la signature produite est tout simplement invalide.
Les programmes de version 0 : P2WPKH, P2WSH et la forme encapsulée
La version 0 compte deux programmes, distingués par leur longueur. Un programme de 20 octets est le hachage d’une clé publique (P2WPKH) : le témoin doit contenir une signature et cette clé. Un programme de 32 octets est le hachage SHA-256 d’un script (P2WSH) : le témoin contient les entrées et le script lui-même, qui peut atteindre 10 000 octets. Le BIP 141 explique ce hachage plus long de 32 octets, contre 20 octets pour P2SH, par la protection contre les attaques par collision, 2 puissance 80 opérations n’étant plus hors d’atteinte.
En 2017, la plupart des portefeuilles et des plateformes ne savaient pas encore payer vers les nouvelles sorties : le BIP 141 a donc défini aussi une forme imbriquée, où le programme témoin est placé dans une sortie P2SH ordinaire, une adresse qui commence par 3. L’expéditeur voit une adresse familière ; le destinataire obtient l’essentiel de la remise sur le témoin au moment de dépenser. Ce SegWit « imbriqué » ou « encapsulé » explique en partie pourquoi la part de P2SH dans le tableau d’adoption plus bas est restée élevée des années après 2017.
Les sorties natives de version 0 ont reçu un nouvel encodage d’adresse, bech32, défini par le BIP 173, avec des adresses qui commencent par bc1q. Les sorties Taproot utilisent bech32m (BIP 350) et commencent par bc1p. Longueurs, sommes de contrôle et raison d’être de bech32m figurent dans notre guide des adresses crypto.
Pourquoi la correction de la malléabilité a compté plus que la remise
Les économies de frais étaient l’argument de vente pour les utilisateurs, mais la fin de la malléabilité était ce qu’attendaient les développeurs. Un canal Lightning s’ouvre par une transaction de financement qui bloque des pièces dans une sortie multisignature 2-sur-2, et chaque partie détient des transactions signées qui dépensent cette sortie avant même qu’elle soit confirmée. Ces dépenses présignées désignent la transaction de financement par son txid. Avec un txid malléable, la contrepartie ou n’importe quel nœud relais pouvait les rendre inutilisables et laisser les pièces bloquées.
Une fois SegWit actif, l’identifiant d’une transaction dont toutes les entrées sont SegWit est fixé à l’instant où elle est signée. Notre guide des réseaux de couche 1 et de couche 2 donne la vue d’ensemble de Lightning ; la prochaine leçon du parcours le traite en profondeur, canaux, routage et limites compris. Taproot est revenu sur Lightning plus tard : Bitcoin Optech a relevé que LND v0.17.0-beta a livré des canaux Taproot et MuSig2 expérimentaux en 2023, et que Core Lightning a fait de Pay-to-Taproot le choix par défaut pour les dépenses d’ancrage et les fermetures unilatérales en novembre 2024.
Taproot : trois BIP et une nouvelle sortie
Taproot est le nom courant de trois documents de Pieter Wuille, Jonas Nick et Anthony Towns (Tim Ruffing à la place de Towns pour le BIP 340) : les signatures de Schnorr (BIP 340), la sortie Taproot et ses règles de dépense (BIP 341), et les règles de script qu’elle contient, le tapscript (BIP 342). Leur sortie, P2TR, est un programme témoin de version 1 avec 32 octets de données, et ces 32 octets sont une clé publique, non un hachage.
Les signatures de Schnorr, vérifiées par une seule équation
Notre guide de la cryptographie présente les signatures de Schnorr en quelques lignes : la même courbe secp256k1 qu’ECDSA, des clés publiques de 32 octets, des signatures de 64 octets. La règle de vérification montre leur intérêt. Une signature est un point R et un nombre s ; elle est valide pour la clé P et le message m quand s fois le générateur G est égal à R plus hash(R, P, m) fois P. Chaque terme est une somme de points, sans inversion ni division, contrairement à ECDSA.
Cette forme est linéaire : les clés et les signatures partielles de plusieurs personnes peuvent s’additionner en une clé et une signature uniques. Le BIP 340 décrit aussi la vérification par lots, où de nombreuses signatures sont contrôlées ensemble plus vite qu’une à une, et la non-malléabilité : une signature valide ne peut pas être réécrite en une autre signature valide, et l’astuce (r, n – s) d’ECDSA disparaît. L’encodage fixe de 64 octets remplace le DER, dont la longueur variable avait causé des problèmes de consensus avant le BIP 66.
La clé ajustée : un arbre de scripts replié dans une clé publique
Une clé de sortie Taproot Q se construit à partir d’une clé interne P et d’un ensemble optionnel de scripts. Les scripts sont les feuilles d’un arbre de Merkle ; sa racine, appelons-la k, est hachée avec P pour donner un nombre t, et la clé de sortie est Q = P + tG. Quiconque connaît P et k peut vérifier que Q s’engage sur eux. Quiconque ne voit que Q voit une clé publique comme une autre. Quand il n’y a aucun script, le BIP 341 recommande tout de même d’ajuster la clé avec un hachage de P seul, pour qu’aucun copropriétaire ne puisse glisser un chemin de script que les autres ignorent.
Le chemin de clé : une signature, rien d’autre de visible
La première façon de dépenser est le chemin de clé : une seule signature de Schnorr de 64 octets valide pour Q, ou de 65 octets si l’on utilise un drapeau sighash non standard. Rien d’autre ne figure dans le témoin. La clé interne, les scripts et même le fait que des scripts aient existé restent hors de la chaîne. Une personne seule avec une seule clé produit exactement cela. Un groupe qui a combiné ses clés en une seule avec MuSig2, le protocole multisignature publié sous le BIP 327, aussi : chaque signataire fournit une signature partielle et le résultat est une signature d’aspect ordinaire.
Le hachage de signature change encore avec le BIP 341. Une signature Taproot s’engage sur les montants et les scripts de sortie de toutes les entrées dépensées, et non de la seule sienne, ce qui, selon le BIP 341, « élimine la possibilité de mentir aux appareils de signature hors ligne sur les frais d’une transaction » (traduction). Le BIP 143 protégeait le montant d’une entrée ; ceci couvre toute la transaction.
Le chemin de script : révéler une seule branche de l’arbre
La seconde façon est le chemin de script, utilisé quand les parties ne peuvent pas ou ne veulent pas toutes signer. Le dépensier révèle un script de feuille, les entrées qui le satisfont et un bloc de contrôle de 33 + 32m octets : un octet pour la version de la feuille et la parité de Q, la clé interne de 32 octets, puis m hachages de 32 octets qui prouvent que la feuille figure dans l’arbre, m valant au plus 128. Les nœuds recalculent la racine, vérifient que P ajustée avec elle donne Q, puis exécutent le script. Seule la branche utilisée est publiée ; les autres feuilles restent cachées.
C’est l’idée longtemps discutée sous le nom de MAST, arbres de syntaxe abstraite de Merkle, livrée avec Taproot. Un contrat à dix issues possibles plaçait autrefois les dix dans un script P2SH ou P2WSH et les révélait toutes à la dépense. Avec Taproot, il n’en révèle qu’une, avec une preuve dont la taille croît avec la profondeur de l’arbre et non avec le nombre de feuilles.
Tapscript : ce qui change à l’intérieur des scripts
Les scripts exécutés sous la version de feuille 0xc0 suivent le BIP 342. OP_CHECKSIG et OP_CHECKSIGVERIFY vérifient désormais des signatures de Schnorr avec des clés de 32 octets. OP_CHECKMULTISIG et OP_CHECKMULTISIGVERIFY sont désactivés, car ils ne se prêtent pas à la vérification par lots : ils essaient les clés dans l’ordre jusqu’à ce que les signatures correspondent. Une politique k-sur-n s’écrit à la place avec le nouvel OP_CHECKSIGADD (opcode 186), qui vérifie une clé et ajoute 1 à un compteur quand la signature est valide ; le script se termine en comparant le compteur à k. L’élément factice décalé de l’ancien opcode, vu à la leçon 1, disparaît avec lui.
Deux limites ont sauté. La limite de 10 000 octets par script ne s’applique pas au tapscript, ni celle de 201 opcodes hors empilement : le BIP 342 dit que la taille n’est « bornée qu’implicitement par la limite de poids du bloc » (traduction). Sa raison tient au coût de vérification, puisque le script n’est plus rehaché à chaque contrôle de signature. Les contrôles de signature ont à la place leur propre budget : 50 plus la taille du témoin de l’entrée, chaque contrôle de signature exécuté coûtant 50. La limite de 520 octets par élément de pile et de 1 000 éléments sur la pile demeure.
Une liste d’opcodes inutilisés est aussi rebaptisée OP_SUCCESSx par le BIP 342 : un script qui en contient un est valide sans condition. Cela paraît imprudent, mais c’est la même porte dérobée que celle des versions de témoin, un étage plus bas. Un futur soft fork peut donner un sens à l’un de ces opcodes et rendre invalides certains de ces scripts, ce qui ne fait que durcir les règles. Les versions de feuille et les types de clé publique inconnus sont gardés libres dans le même but.
Un exemple détaillé : un coffre d’épargne 2-sur-3 avec chemin de récupération
Un montage illustratif montre les deux chemins ensemble. Trois clés appartiennent à Alice, Bob et un service de sauvegarde ; deux d’entre elles quelconques peuvent dépenser, et après un an sans mouvement une clé de récupération distincte peut balayer seule les pièces. La clé interne est un agrégat MuSig2 des clés d’Alice et de Bob, le duo censé signer la plupart du temps. L’arbre a trois feuilles : Alice plus la sauvegarde, Bob plus la sauvegarde, et la clé de récupération derrière un verrou temporel relatif de 52 560 blocs (environ un an), le verrou OP_CHECKSEQUENCEVERIFY expliqué à la leçon 1.
Un jour normal, Alice et Bob signent ensemble par le chemin de clé. La chaîne voit une signature de 64 octets, une entrée d’environ 57,5 vbytes, et rien qui indique l’existence d’un coffre, d’un service de sauvegarde ou d’un plan de récupération. Si Bob perd son téléphone, Alice et la sauvegarde dépensent par leur feuille : la chaîne voit cette seule feuille avec ses deux clés et ses deux signatures, plus un bloc de contrôle d’un ou deux hachages, et toujours rien de la branche de récupération. En P2WSH, la même politique mettrait sur la chaîne toutes les clés et toute la condition de verrou temporel à chaque dépense.
Legacy, SegWit et Taproot côte à côte
Les tailles viennent du calculateur de taille de transaction de Bitcoin Optech, qui suppose des signatures ECDSA de 72 octets (la borne haute ; la signature à faible R les ramène à 71) et des clés compressées de 33 octets. L’entrée SegWit imbriquée est la somme de Coindaro à partir des mêmes tailles de champs : 64 octets hors témoin et un témoin de 108 octets, soit 64 + 27 = 91 vbytes.
| Legacy P2PKH | SegWit imbriqué (P2SH-P2WPKH) | SegWit natif P2WPKH | Taproot P2TR | |
|---|---|---|---|---|
| L’adresse commence par | 1 | 3 | bc1q | bc1p |
| Version du témoin | aucune | 0, dans un P2SH | 0 | 1 |
| Signature | ECDSA, DER, 71-72 octets | ECDSA | ECDSA | Schnorr, 64-65 octets |
| Taille d’une entrée (clé unique) | 148 vB | environ 91 vB | 68 vB | 57,5 vB (chemin de clé) |
| Taille d’une sortie | 34 vB | 32 vB | 31 vB | 43 vB |
| Données de signature dans le txid | oui (malléable) | non | non | non |
| Ce que révèle une dépense | clé et signature | clé, signature, script d’enveloppe | clé et signature | une signature (chemin de clé) ou une feuille de script |
| Exemple d’entrée multisignature | P2SH 2-sur-3 : 297 vB | non calculé | P2WSH 2-sur-3 : 104,5 vB | 57,5 vB si les signataires agrègent leurs clés |
Un exemple étiqueté rend l’arbitrage concret : une entrée, une sortie de paiement et une sortie de monnaie rendue, toutes du même type. En P2PKH legacy, cela fait 10 + 148 + 2 x 34 = 226 vB. En P2WPKH, 10,5 + 68 + 2 x 31 = 140,5 vB. En P2TR, 10,5 + 57,5 + 2 x 43 = 154 vB. À 3 sat/vB, le taux le plus rapide affiché par mempool.space à 10:23 UTC le 9 novembre 2026, cela donne 678, environ 422 et 462 satoshis.
Un paiement Taproot à clé unique de cette forme est donc un peu plus gros qu’un paiement SegWit natif : la sortie porte une clé de 32 octets au lieu d’un hachage de 20 octets, et c’est l’expéditeur qui paie les sorties. Le destinataire paie plus tard pour les entrées, où Taproot est plus léger de 10,5 vbytes à chaque fois. Un portefeuille qui reçoit beaucoup de petits paiements et les dépense plus tard économise à la sortie ; celui qui envoie beaucoup de paiements avec monnaie rendue paie un peu plus à l’entrée. Pour la garde partagée, la comparaison bascule nettement en faveur de Taproot, comme le montre la ligne multisignature, mais seulement quand les signataires peuvent exécuter MuSig2 ou un protocole comparable.
Ce qui a changé pour les frais et la confidentialité, et ce qui n’a pas changé
Le gain de frais de SegWit vient de la remise sur le témoin et de scripts plus petits, et il est important : environ 38 % de vbytes en moins pour l’exemple à une entrée ci-dessus. Le gain de Taproot est faible pour les clés uniques et grand pour les politiques à plusieurs clés ou conditions. Ni l’un ni l’autre ne change le marché des frais lui-même : un taux de frais reste fixé par la concurrence pour l’espace dans les blocs, comme l’explique le guide du mempool.
La confidentialité a progressé d’une façon précise. Avant Taproot, une dépense montrait quelle sorte de verrou elle ouvrait, clé unique, multisignature, verrou temporel ou verrou de hachage, et souvent toutes ses conditions. Une dépense Taproot par le chemin de clé a le même aspect pour une personne, pour une entreprise qui a une politique à trois clés et pour un canal Lightning fermé d’un commun accord. Cela ne fonctionne que si beaucoup de gens utilisent le même type de sortie ; un type rare est en soi une empreinte.
Ce que Taproot n’a pas changé compte autant. Les montants sont publics. Les adresses sont publiques, et réutiliser une adresse relie toujours les paiements. Une transaction à plusieurs entrées laisse toujours penser à un propriétaire commun, l’heuristique expliquée dans notre guide des modèles UTXO et à comptes, parce que Taproot n’a pas inclus l’agrégation de signatures entre entrées : chaque entrée porte toujours sa propre signature. Le BIP 341 dit que cette idée a été laissée de côté parce qu’elle « interagit de façon complexe avec les mécanismes de mise à niveau » (traduction). Une dépense par le chemin de script révèle aussi qu’un script existait, et lequel a servi.
Qui utilise SegWit et Taproot : des instantanés datés
Il n’existe pas de série officielle unique de l’adoption, et le résultat dépend de ce qu’on compte : transactions, entrées, sorties ou vbytes. Le tableau est le décompte de Coindaro sur des blocs bruts lus sur mempool.space le 9 novembre 2026, et chaque ligne est un échantillon, non une moyenne : quatre blocs (un bloc sur trois à partir du premier indiqué, vers 00:00 UTC à cette date), chaque transaction analysée, chaque sortie classée d’après son script. « Avec témoin » compte les transactions qui portent des données témoins, donc, à partir de 2021, Taproot compris. Les parts de sorties sont calculées sur toutes les sorties créées, sorties de données comprises. La dernière colonne donne la part des entrées qui ressemblent à une dépense Taproot par le chemin de clé, un seul élément de témoin de 64 ou 65 octets.
| Date de l’échantillon | Blocs | Tx avec témoin | Sorties P2PKH | Sorties P2SH | Sorties P2WPKH | Sorties P2TR | Sorties OP_RETURN | Entrées Taproot chemin de clé |
|---|---|---|---|---|---|---|---|---|
| 1er août 2017 | 478 478 à 478 487 | 0,0 % | 84,0 % | 14,8 % | 0 % | n.d. | 1,1 % | n.d. |
| 1er nov. 2017 | 492 557 à 492 566 | 9,2 % | 84,4 % | 15,3 % | 0 % | n.d. | 0,2 % | n.d. |
| 1er nov. 2018 | 548 213 à 548 222 | 36,4 % | 53,2 % | 35,2 % | 4,3 % | n.d. | 7,1 % | n.d. |
| 1er nov. 2019 | 601 841 à 601 850 | 46,7 % | 48,8 % | 36,1 % | 10,4 % | n.d. | 3,6 % | n.d. |
| 1er nov. 2020 | 654 932 à 654 941 | 39,0 % | 43,6 % | 43,4 % | 11,1 % | n.d. | 0,5 % | n.d. |
| 1er nov. 2021 | 707 633 à 707 642 | 81,1 % | 20,9 % | 44,7 % | 30,3 % | n.d. | 0,7 % | n.d. |
| 1er nov. 2022 | 761 191 à 761 200 | 81,0 % | 20,5 % | 38,8 % | 35,6 % | 0,2 % | 0,4 % | 0,5 % |
| 1er nov. 2023 | 814 748 à 814 757 | 95,3 % | 9,4 % | 16,0 % | 38,1 % | 30,0 % | 4,2 % | 13,6 % |
| 1er nov. 2024 | 868 326 à 868 335 | 98,3 % | 4,9 % | 4,8 % | 41,2 % | 23,8 % | 24,2 % | 20,0 % |
| 1er nov. 2025 | 921 682 à 921 691 | 96,8 % | 5,0 % | 3,7 % | 46,2 % | 22,3 % | 20,8 % | 7,3 % |
| 1er nov. 2026 | 974 043 à 974 052 | 98,9 % | 1,9 % | 1,7 % | 54,3 % | 3,7 % | 37,4 % | 4,7 % |
Quatre blocs sont un échantillon, non une courbe de tendance, et les colonnes Taproot le prouvent : 30,0 % des sorties en novembre 2023, 3,7 % trois ans plus tard, avec des écarts entre les deux qui suivent les vagues d’inscriptions et de sorties de données plus que tout choix régulier des portefeuilles. La série montre en revanche la forme générale. Les sorties P2PKH legacy sont passées de plus de 80 % à 1,9 % de toutes les sorties dans l’échantillon de novembre 2026. SegWit est passé de rien à presque toutes les transactions des blocs échantillonnés en environ six ans, avec une montée lente jusqu’en 2020 et un saut en novembre 2021. Les clés SegWit natives de version 0 sont aujourd’hui le verrou dominant, et Taproot est un type minoritaire dont la part dépend de ce qui se passe d’autre dans les blocs.
Un échantillon plus large donne une image plus stable. Sur les 144 blocs consécutifs 975 014 à 975 157, horodatés entre 02:15 UTC le 8 novembre et 09:30 UTC le 9 novembre 2026, Coindaro a compté 537 583 transactions, dont 89,9 % contenaient des données témoins. Sorties de données mises à part, les 1 041 956 sorties dépensables créées dans ces blocs se répartissaient en 69,6 % de P2WPKH, 10,5 % de P2TR, 6,8 % de P2PKH, 5,9 % de P2SH et 3,4 % de P2WSH. Sur 1,2 million d’entrées, 9,5 % ressemblaient à des dépenses Taproot par le chemin de clé et 13,2 % se trouvaient dans des transactions sans aucun témoin. Un bloc de cette fenêtre, le 975 157, contenait environ 7 959 transactions qui associaient presque toutes une sortie SegWit native à une sortie de données, de quoi à lui seul déplacer les parts de sorties de la journée.
Comment les portefeuilles et les nœuds ont suivi
Des règles actives dans un bloc ne signifient pas que les portefeuilles les utilisent. Bitcoin Core a livré la validation de SegWit dans la version 0.13.1 le 27 octobre 2016, dix mois avant l’activation, mais son propre portefeuille n’a fait de SegWit natif le choix par défaut qu’avec la 0.20.0, publiée le 3 juin 2020, dont les notes disent que le portefeuille « utilise désormais par défaut des adresses bech32 via RPC et crée des sorties de monnaie rendue en SegWit natif » (traduction). La lente montée de la colonne des témoins entre 2018 et 2020 correspond à ce rythme, les adresses imbriquées servant de pont. Taproot a répété le décalage : payer une adresse bc1p exige un logiciel qui connaît bech32m, ce que le guide des adresses date de 2021 pour les premiers portefeuilles, et les outils multipartites sont arrivés plus tard encore, puisque les signataires MuSig2 doivent échanger des nonces en plusieurs tours avant qu’une signature existe.
Comment Taproot en est venu à stocker des images : le lien avec Ordinals
Les concepteurs de Taproot ont écrit sur le coût des signatures et sur la confidentialité, pas sur le stockage de fichiers. Pourtant, les vagues d’inscriptions qui font bouger la colonne Taproot ci-dessus reposent justement sur deux de ses fonctions. La documentation d’Ordinals énonce le mécanisme : « Le contenu d’une inscription est entièrement sur la chaîne, stocké dans des scripts de dépense par chemin de script Taproot. » (traduction) Les données se trouvent dans une enveloppe, OP_FALSE OP_IF suivi du contenu et d’OP_ENDIF, une branche qui ne s’exécute jamais, si bien que le script autour fonctionne normalement.
Deux règles du tapscript rendent la chose praticable. Sans la limite de 10 000 octets, un script de feuille peut être aussi grand que le permet le poids du bloc, et comme le script est révélé dans le témoin, chacun de ses octets compte une unité de poids au lieu de quatre. La limite de 520 octets par élément de pile s’applique toujours : le contenu est donc découpé en empilements de 520 octets au plus. Comme un chemin de script ne peut servir qu’en dépensant une sortie Taproot existante, une inscription demande deux transactions : un engagement qui crée la sortie, et une révélation qui la dépense et inscrit le contenu sur la chaîne.
Savoir s’il s’agit d’un usage légitime de l’espace des blocs ou de spam est un débat que cette leçon ne tranche pas. Il a mené à la tentative de 2026 de limiter ces données par soft fork, le BIP-110, racontée dans le guide des forks, et c’est l’un des débats de la leçon sur la gouvernance plus loin dans le parcours. Ordinals, les jetons BRC-20 et Runes auront leur propre leçon, après celle sur l’exploitation d’un nœud.
Les clés exposées de Taproot et le débat quantique
Une sortie P2PKH ou P2WPKH stocke un hachage de la clé publique ; la clé elle-même n’apparaît qu’au moment de la dépense. Une sortie Taproot stocke la clé, ajustée mais utilisable, dans la sortie dès le jour où la pièce arrive. Si une machine capable de résoudre le logarithme discret sur courbe elliptique existait un jour, toutes les sorties Taproot non dépensées seraient exposées aussi longtemps qu’elles resteraient sur la chaîne.
Le sujet est traité dans une note de bas de page du BIP 341, qui le minimise. Ce texte soutient que cacher une clé derrière un hachage n’offre qu’une protection « très faible au mieux » (traduction), puisque les clés sont révélées dans le mempool à chaque dépense et qu’une large part des pièces repose déjà derrière des clés exposées, et qu’une vraie résistance exige une autre cryptographie. Les auteurs du BIP 360 en tirent une autre conclusion. Leur proposition, numérotée le 18 décembre 2024 et toujours à l’état de Draft (version 0.12.1 le 9 novembre 2026), ajoute un nouveau type de sortie, Pay-to-Merkle-Root, qui conserve les arbres de scripts de Taproot et supprime le chemin de clé. Elle reconnaît sa limite en ces termes : « Les sorties Bitcoin sont en général vulnérables aux attaques à courte exposition, car la plupart des transactions Bitcoin exigent de révéler la clé publique associée à la dépense. » (traduction)
Les estimations de la date à laquelle une telle machine pourrait exister varient largement et aucune n’est établie. Coindaro a couvert l’une des plus récentes, l’étude d’Alice et Bob sur les qubits de chat et la courbe de Bitcoin, dont les chiffres reposent sur des hypothèses qu’aucune machine existante ne remplit. Le BIP 360 est une proposition, non une règle, et la liste des propositions ouvertes relève de la leçon sur la gouvernance.
Faut-il choisir une adresse SegWit ou Taproot dans son portefeuille ?
Beaucoup de portefeuilles proposent de recevoir en SegWit natif (bc1q) ou en Taproot (bc1p), et certains offrent encore les types imbriqué (3…) et legacy (1…). Les quatre restent valides et dépensables ; aucune règle ne les retire. Le tableau des tailles donne l’arbitrage sur les frais, et la section précédente le seul coût que Taproot ajoute, une clé exposée sur la chaîne pendant que les pièces attendent. Une vérification s’impose encore avant de changer : s’assurer que les personnes ou les services qui vous paient peuvent envoyer vers le type choisi. Un expéditeur qui refuse une adresse bc1p utilise le plus souvent un logiciel sans bech32m, et ce n’est pas une faute de frappe.
Déplacer d’anciennes pièces vers un type d’adresse plus récent est une transaction vers soi-même, et elle paie des frais comme n’importe quelle autre. Si vous vendez ensuite du bitcoin avec une plus-value, les gains réalisés en 2026 relèvent en France du prélèvement forfaitaire unique de 31,4 %, selon la page de l’administration fiscale sur la déclaration des plus-values et moins-values d’actifs numériques (mise à jour le 17 juillet 2026). Notre guide de la fiscalité des cryptos en France détaille le calcul et les justificatifs à conserver.
Ce qu’il faut retenir sur SegWit et Taproot
- SegWit (2017) et Taproot (2021) sont des soft forks qui utilisent tous deux les versions de témoin, des sorties que les anciens nœuds traitent comme dépensables par n’importe qui.
- SegWit a sorti les signatures du txid, ce qui a mis fin à la malléabilité par des tiers pour les dépenses SegWit et rendu possible la construction sûre de canaux de paiement.
- Taproot place une clé publique ajustée dans la sortie ; elle se dépense avec une seule signature de Schnorr ou en révélant un script d’un arbre caché.
- Une sortie Taproot à clé unique est plus grosse qu’une sortie SegWit native et son entrée plus petite ; le gain est surtout net avec des clés partagées.
- Les échantillons de blocs de Coindaro montrent des données témoins dans environ neuf transactions sur dix ou plus en 2026, et Taproot comme un type minoritaire dont la part varie avec les vagues d’inscriptions.
La prochaine leçon du parcours aborde le Lightning Network, le système de canaux de paiement qui dépend des identifiants de transaction stables apportés par SegWit.
