Blockchain/Niveau IV · Le protocole en profondeur/4.1 Script/Leçon 7
Segregated Witness et malléabilité des transactions
L’identifiant instable, la signature séparée et le correctif qui a débloqué Lightning
MatérielUn explorateur de blocs capable de fournir une sortie JSONUne chaîne hexadécimale de transaction P2PKH pré-SegWit (de 2016 ou avant)Une chaîne hexadécimale de transaction P2WPKH post-SegWit
Curiosité
- Pourquoi un inconnu pouvait-il modifier l’identité d’une transaction sans en compromettre la validité ?
- Comment le fait de sortir les signatures du hachage permet-il de corriger la malléabilité tout en les maintenant protégées par le consensus ?
- Qu’est-ce que le poids d’un bloc, et pourquoi la décote appliquée aux données de témoin a-t-elle augmenté la capacité ?
Explorer
- Avant SegWit, l’identifiant d’une transaction (txid) était le double SHA-256 de toute la transaction, signatures comprises. Un tiers pouvait réencoder une signature, par exemple en remplaçant sa valeur s par son opposé ou en modifiant la façon dont elle était poussée sur la pile, sans l’invalider, ce qui produisait un nouveau txid pour le même paiement. Cette malléabilité cassait les chaînes non confirmées : si la transaction fille d’Alice référençait sa transaction mère par son identifiant, une version malléabilisée de la transaction mère la rendait orpheline, semant la confusion dans les portefeuilles et les plateformes d’échange qui suivaient les paiements.
- En février 2014, Mt. Gox a invoqué ce mécanisme pour expliquer le chaos interne lors de son effondrement, bien que des analyses ultérieures aient montré qu’il n’expliquait qu’une faible part des pertes déclarées. La vulnérabilité persistait parce que les signatures ECDSA sont intrinsèquement malléables dans leur représentation en octets ; des tiers, et, après BIP66 et les règles low-S, principalement les mineurs, pouvaient les réécrire. Cette instabilité rendait dangereuse la construction de canaux de paiement bidirectionnels comme Lightning, où les états des canaux dépendent d’identifiants de transaction précis et prévisibles avant confirmation.
- Segregated Witness (BIP141), activé le 24 août 2017 au bloc 481 824, a résolu ce problème en séparant les données de témoin du corps de la transaction. Le txid ne hache désormais que les champs hors témoin, ce qui le rend insensible aux changements d’encodage des signatures. Les témoins restent dans une structure distincte au sein de la transaction brute, mais sont exclus du hachage d’identité. Les tiers ne peuvent plus modifier le txid, tandis que les signatures restent pleinement vérifiées par le consensus.
- Les données de témoin font l’objet d’un engagement via un arbre de Merkle référencé dans la transaction coinbase de chaque bloc, ce qui garantit qu’elles ne peuvent être supprimées ou modifiées sans invalider le bloc. Bien que séparés du txid, les témoins comptent toujours dans les limites de taille des blocs, selon une nouvelle métrique de « poids » : 4 000 000 d’unités de poids par bloc. Chaque octet hors témoin compte pour 4 unités de poids et chaque octet de témoin pour 1, si bien que les transactions riches en signatures y tiennent plus facilement.
- BIP143 a introduit un nouveau schéma de hachage des signatures qui a supprimé le coût de hachage quadratique des transactions comportant de nombreuses entrées. BIP141 a défini les programmes de témoin de version 0, P2WPKH et P2WSH, devenus la norme pour les nouvelles adresses, et BIP144 a précisé la façon dont les données de témoin circulent entre pairs. Ces changements ont non seulement corrigé la malléabilité, mais ont aussi posé les bases de mises à niveau futures comme Taproot, en établissant un cadre de programmes de témoin versionnés qui permet de faire évoluer les scripts sans rompre les règles de consensus existantes.
- Ouvrez un explorateur de blocs et repérez une transaction P2WPKH récente. Examinez-la : les signatures figurent dans un champ « witness » distinct et non dans le scriptSig de l’entrée, et le txid est calculé sans elles. Comparez-la à une transaction P2PKH de 2016, antérieure à SegWit, où les signatures se trouvent dans le scriptSig et entrent donc dans le calcul du txid. Cette séparation visuelle confirme que les données de témoin n’influent plus sur l’identité de la transaction.
Faits clés
- Segregated Witness a été activé le 24 août 2017, au bloc 481 824.
- La malléabilité des transactions permettait à des tiers de changer un txid en modifiant l’encodage de la signature ECDSA, sans invalider la transaction.
- BIP141 a déplacé les signatures dans une structure de témoin distincte, exclue du calcul du txid.
- Le poids d’un bloc est plafonné à 4 000 000 d’unités, les données de témoin bénéficiant d’une décote d’un facteur quatre par rapport aux données hors témoin.
- BIP143 a introduit un schéma de hachage des signatures qui a éliminé les coûts de hachage quadratiques pour les transactions ayant de nombreuses entrées.
- BIP141 a introduit des programmes de témoin numérotés par version (version 0 : P2WPKH et P2WSH), laissant la place à des versions ultérieures comme Taproot.
Exercice neuf, six, trois, un
9RassemblerÉnumérez 9 conséquences techniques ou économiques de la malléabilité des transactions avant 2017. Indiquez pour chacune qui elle a touché : utilisateurs, portefeuilles, plateformes d’échange ou développeurs du protocole.
6RegrouperRegroupez les 9 en 6 catégories : instabilité de l’identifiant, ruptures des chaînes non confirmées, confusion des plateformes d’échange, impossibilité des canaux, mutabilité de l’encodage des signatures et lacunes de protection par le consensus.
3DistillerRéduisez les 6 à 3 raisons fondamentales pour lesquelles la malléabilité empêchait des canaux de paiement scalables avant SegWit.
1CristalliserRédigez 1 phrase expliquant comment le fait de séparer les données de témoin du hachage du txid assure à la fois la stabilité de l’identifiant et ouvre la voie à de futures évolutions des scripts.
Vérification des faits
Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.