Pierre Noizat, co-fondateur de Paymium (Bitcoin-Central), vient de publier sur e-ducat.fr, un article consacré à la désormais fameuse « malléabilité des transactions » qui a surgi dans l’actualité de Bitcoin comme un diable hors de sa boite… le problème est pourtant connu depuis longtemps.
« Le problème de la « malléabilité » des transactions Bitcoin est remonté à la surface ces derniers jours quand MtGox a donné des explications à l’arrêt des retraits en bitcoin sur sa plate-forme. Ce problème n’est pas nouveau car il a déjà été discuté sur les forums dès le printemps 2011. De quoi s’agit-il ? Supposons qu’un fraudeur fasse un retrait de bitcoins depuis son compte MtGox. MtGox émet une transaction sur le réseau et donne l’ID de transaction à son client peu scrupuleux.
L’empreinte (hash) d’une transaction bitcoin est son ID dans la chaîne de blocs
Le fraudeur peut capter la transaction bitcoin (rappelez-vous, elles sont signées mais pas cryptées) émise par MtGox et modifier légèrement le format d’une signature sans que cette signature cesse d’être valide. Ce faisant, le fraudeur peut donc diffuser cette même transaction (mêmes adresses, mêmes clés publiques, mêmes montants et signatures valides) avec une ID de transaction différente car quelques bits sont différents de la transaction reçue à l’origine. En minant ou en collaborant avec un pool de minage, le fraudeur peut réussir à inscrire la transaction modifiée dans la blockchain avant que la transaction originale soit inscrite. Dans ce cas, la transaction originale ne passera plus auprès des mineurs car elle sera considérée comme une tentative de double-dépense. Notre fraudeur peut donc maintenant se retourner vers MtGox en prétendant que la transaction originale n’a pas été reçue : si le système comptable de MtGox ne peut pas retrouver automatiquement la trace d’une transaction dans la blockchain autrement qu’avec l’ID de transaction, MtGox a un problème et doit arrêter les retraits si son équipe support est submergée de réclamations de ce genre. C’est ce qui s’est passé. MtGox n’a pas d’autre choix que de mettre à jour ses systèmes comptables afin de pouvoir retrouver automatiquement une transaction par le montant, l’adresse de destination et un index propriétaire qui permet de distinguer une transaction si le client fait rapidement plusieurs demandes de retraits du même montant vers la même adresse.
Techniquement, il s’agit simplement d’une particularité de la libraire openssl utilisée par le client bitcoin de référence. Lorsque le client bitcoin fabrique une signature, il utilise un format appelé DER (Distinguished Encoding Rules) dans la norme X.690, qui est une norme internationale de l’ ITU-Tl ASN.1 spécifiant comment des données doivent être encodées dans un flux binaire. Ce format est sans ambiguïté de sorte que, au moins depuis la version 0.8 du client Bitcoin de référence, les signatures fabriquées par ce client sont conformes. Cependant, ce même client utilise la librairie openssl pour décoder les signatures qu’il reçoit et cette librairie est plutôt tolérante vis-à-vis de la norme DER : un format de signature légèrement modifié par rapport à la norme DER sera accepté par le client Bitcoin.
Les développeurs du « core team » de Gavin Andresen ont donc le choix entre s’appuyer sur une librairie standard (openssl) avec cette « malléabilité » ou bien intégrer leur propre implémentation du décodage des signatures, plus rigoureuse, en perdant le bénéfice de la compatibilité avec une librairie standard. Jusqu’à présent ils ont préféré la compatibilité ce qui doit inciter les « exchanges » à prendre en compte la malléabilité dans leurs systèmes comptables. C’est ce que fait Bitcoin-central dont les clients n’ont pas été affectés par les problèmes de retraits que les clients des autres exchanges (MtGox, bitstamp, etc) ont connus […] »
Source : e-ducat.fr
« Les transactions Bitcoin sont identifiés par un hash hexadécimal de 64 chiffres appelé identifiant de transaction (txid) lequel est basé sur les fonds dépensés d’une part et sur qui sera capable de dépenser les résultats de la transaction d’autre part.
Malheureusement, la façon dont le txid est calculé permet à quiconque de faire de petites modifications à la transaction qui ne changeront pas sa signification, mais qui vont changer le txid. Ceci est appelé la malléabilité par un tiers. BIP 62 (“traiter la malléabilité”) a tenté de répondre à ces questions d’une manière fragmentaire, mais était trop compliqué à mettre en œuvre à l’aide de contrôles de consensus et a été retirée.
Par exemple, vous pourriez émettre une transaction avec le txid ef74…C309 sur le réseau, mais constater qu’un tiers, comme un nœud sur le réseau relayant votre transaction, ou le mineur qui inclut votre transaction dans un bloc, modifie légèrement la transaction, résultant en une transaction qui dépense les mêmes fonds et paye les mêmes adresses, mais est confirmée sous un txid totalement différent 683f…8bfa.
Plus généralement, si un ou plusieurs des signataires de la transaction modifient leurs signatures alors la transaction reste valable et paie les mêmes montants aux mêmes adresses, mais le txid change complètement car il intègre les signatures. Le cas général où des modifications sont apportées aux données de signature (mais pas des sorties ou une sélection d’entrées) et qui modifient donc la transaction est appelé la malléabilité scriptSig.
Segwit empêche la malléabilité par un tiers et la malléabilité scriptSig en permettant aux utilisateurs Bitcoin de déplacer les parties malléables de la transaction dans le témoin de la transaction (transaction witness), et de séparer ce témoin afin que les changements apportés au témoin n’affectent pas le calcul du txid. » – Source : bitcoincore.org
