Qu'est-ce que la malléabilité d'une transaction et comment a-t-elle été abordée dans Bitcoin ?

Comprendre la malléabilité des transactions dans Bitcoin

1. La malléabilité d'une transaction fait référence à la capacité de modifier l'identifiant unique d'une transaction (ID de transaction ou TXID) sans modifier son effet économique, tel que l'expéditeur, le destinataire ou le montant de Bitcoin transféré. Cela se produit parce que certaines parties d'une transaction Bitcoin, en particulier le script de signature (également connu sous le nom de scriptSig), peuvent être modifiées avant confirmation tout en permettant à la transaction d'être considérée comme valide par le réseau.

2. Étant donné que le TXID est dérivé du hachage de l'intégralité des données de transaction, toute modification du format de signature, même s'il reste cryptographiquement valide, entraîne un hachage différent. Cela signifie que quelqu'un pourrait intercepter une transaction, modifier légèrement sa structure de signature, la rediffuser et semer la confusion quant à savoir si la transaction originale a été confirmée ou non.

3. Ce problème a créé des problèmes importants pour les bourses et les services de portefeuille qui reposaient sur le suivi des transactions non confirmées à l'aide de TXID. Par exemple, si un utilisateur initie un retrait et que l'ID de la transaction a été modifié en raison de la malléabilité, le système peut supposer à tort que la transaction a échoué et autoriser un autre retrait, ce qui peut entraîner une double dépense ou des erreurs comptables.

4. La vulnérabilité a été exploitée lors de plusieurs incidents très médiatisés, notamment les attaques contre le mont Gox en 2014. La bourse a revendiqué des pertes dues à la malléabilité des transactions, bien que des enquêtes plus approfondies suggèrent qu'une mauvaise gestion interne a joué un rôle plus important. Néanmoins, l’incident a mis en évidence les risques réels associés aux transactions malléables.

Comment les témoins séparés ont résolu le problème

1. La solution la plus efficace et la plus largement adoptée pour la malléabilité des transactions est venue avec l'introduction de Segregated Witness (SegWit) en août 2017. SegWit a séparé (ou séparé) les données des témoins (signatures) des données principales de la transaction, les déplaçant dans une structure distincte qui n'affecte pas le calcul de l'ID de la transaction.

2. En supprimant les signatures des entrées lors du calcul du TXID, SegWit s'est assuré que les modifications apportées à la signature ne modifiaient plus le hachage de la transaction. Cela rendait les transactions immuables en termes d'identifiants une fois diffusées, éliminant ainsi la malléabilité des tiers.

3. En plus de corriger la malléabilité, SegWit a fourni d'autres avantages tels qu'une capacité de bloc accrue grâce à un nouveau calcul du poids des blocs et des capacités de script améliorées. Il a également jeté les bases de solutions de deuxième couche telles que Lightning Network, qui reposent sur des identifiants de transaction stables et prévisibles.

4. L’adoption nécessitait un soft fork, ce qui signifie des modifications rétrocompatibles du protocole. Les nœuds qui n'ont pas été mis à niveau pouvaient toujours valider les blocs, mais ceux qui appliquaient les règles SegWit rejetaient les versions malléées des transactions. Au fil du temps, les principaux portefeuilles, bourses et pools miniers ont adopté SegWit, augmentant ainsi son efficacité sur l'ensemble du réseau.

Approches alternatives avant SegWit

1. Avant SegWit, les développeurs tentaient d'atténuer la malléabilité grâce aux meilleures pratiques et à des correctifs partiels. Une approche consistait à encourager l’utilisation uniquement d’encodages de signature canoniques, en décourageant les formats non standard permettant une manipulation facile.

2. Certains logiciels de portefeuille ont commencé à rechercher des vecteurs de malléabilité connus et à rejeter les transactions utilisant des signatures non codées DER ou incluant des éléments de pile inutiles. Il s’agissait de mesures préventives plutôt que de solutions protocolaires.

3. Une autre idée proposée consistait à exiger que toutes les transactions s'engagent à respecter exactement leurs scripts d'entrée dans les sorties, ce qui rendrait tout changement invalidant la dépense. Cependant, cela aurait nécessité un hard fork et introduit de la complexité, c'est pourquoi cette solution n'a pas été retenue.

4. Il y a également eu des discussions sur l'introduction de nouveaux formats de transaction ou de nouveaux numéros de version pour signaler la protection contre la malléabilité, mais aucune n'a gagné du terrain jusqu'à ce que SegWit propose un correctif complet dans un cadre déployable.

Foire aux questions

Qu'est-ce qui rend une transaction Bitcoin malléable ? La malléabilité des transactions survient parce que les données de signature dans le script d'entrée peuvent être modifiées d'une manière qui reste valide selon les règles de consensus de Bitcoin mais modifie le hachage global de la transaction. Les exemples incluent l'ajout de zéro octet aux signatures ou la modification des opcodes pushdata.

SegWit élimine-t-il complètement la malléabilité des transactions ? Oui, SegWit élimine la malléabilité des transactions tierces en garantissant que l'ID de transaction est calculé sans inclure les données de signature mutables. Seul le créateur d'une transaction peut modifier son identifiant, empêchant ainsi les acteurs externes de falsifier les TXID.

Les transactions non SegWit peuvent-elles toujours être malléées ? Oui, les transactions héritées Bitcoin qui n'utilisent pas SegWit restent susceptibles d'être malléables. Cependant, à mesure que l’adoption de SegWit se développe, la prévalence et l’impact de la malléabilité dans le réseau au sens large continuent de diminuer.

Pourquoi Bitcoin n'a-t-il pas corrigé la malléabilité plus tôt ? Le problème a été reconnu des années avant SegWit, mais la mise en œuvre d'un correctif nécessitait une coordination minutieuse pour éviter les divisions de la chaîne. Concevoir une solution rétrocompatible comme SegWit a pris du temps, surtout compte tenu de la nature décentralisée du développement de Bitcoin et de la nécessité d'un large consensus.