Malléabilité des transactions

Le paiement fonctionnait toujours ; seul son nom avait changé. Bitcoin a comblé la faille par étapes entre 2015 et 2017, et SegWit a achevé le travail pour les entrées qui conservent les signatures dans le witness. Les entrées héritées restent malléables, ce qui est une raison de plus de détenir ses bitcoins à une adresse bc1.

Comment cela fonctionne

Un identifiant de transaction est un hash des octets de la transaction, donc modifier un octet produit un identifiant différent, et dans une entrée héritée la signature fait partie de ces octets.

Trois formes de latitude rendaient une modification possible sans rien casser.

La première est arithmétique. Une signature ECDSA est une paire de nombres, r et s, et pour chaque s valide il existe une seconde valeur tout aussi valide, l'ordre de la courbe moins s. Quiconque observe le réseau peut l'inverser et la vérification réussit toujours.

La deuxième est l'encodage. Les signatures étaient encapsulées en DER, et la bibliothèque sur laquelle bitcoin s'appuyait acceptait des variantes négligées : octets de tête nuls superflus, marqueurs de longueur non canoniques, remplissage qu'aucun encodeur soigneux n'émettrait. Chaque variante donnait un identifiant différent une fois hachée.

La troisième est le script de déverrouillage autour de la signature. Pousser un élément supplémentaire inoffensif sur la pile laissait le résultat du script identique et les octets sérialisés différents.

Les correctifs sont arrivés une couche à la fois. Le BIP66 a fait de l'encodage DER strict une règle de consensus à la hauteur 363 725 le 4 juillet 2015, une activation dont on se souvient surtout parce que plusieurs grands pools construisaient sur des en-têtes qu'ils n'avaient pas validés et ont produit une bifurcation de six blocs cet après-midi-là. Bitcoin Core 0.11.1, publié en octobre 2015, a fait des valeurs s basses une règle de politique de relais, formalisée plus tard comme BIP146. Le BIP62, une tentative d'énumérer et d'interdire toutes les sources restantes, a été abandonné comme impraticable et porte encore aujourd'hui le statut Withdrawn. Ce qui a réglé la question, c'est SegWit, actif à la hauteur 481 824 le 24 août 2017 : les signatures sont passées dans le witness, l'identifiant est calculé sans le witness, et pour une entrée segwit il ne reste simplement rien à muter.

Où cela se manifeste

La malléabilité n'a jamais causé de vol, elle a causé des erreurs de comptabilité, et c'est encore la forme du risque.

Un dépositaire qui suivait les retraits par l'identifiant qu'il diffusait pouvait se voir présenter une transaction confirmée portant un identifiant différent, en conclure que son propre paiement avait échoué et envoyer les bitcoins à nouveau. Ce schéma a causé des pertes réelles sur des plateformes d'échange en 2014, et c'est pourquoi les opérateurs sérieux rapprochent les opérations par adresse de sortie et montant plutôt que par identifiant seul.

Les transactions en chaîne ont été l'autre victime. Une transaction enfant qui dépense une transaction parente non confirmée désigne celle-ci par son identifiant, donc une transaction parente modifiée laisse l'enfant définitivement impossible à dépenser. Tout protocole qui signe un remboursement avant la diffusion de la transaction de financement, ce qui est exactement ce que fait l'ouverture d'un canal Lightning, était dangereux à construire jusqu'à ce que les identifiants deviennent stables.

Pour quelqu'un qui achète et conserve, une seule habitude couvre tout cela. Un identifiant non confirmé n'est pas un fait. Il peut encore changer par malléabilité sur les entrées héritées, et il change désormais couramment pour une raison sans rapport, parce que Bitcoin Core relaie le full replace-by-fee par défaut et qu'un expéditeur qui augmente les frais publie un nouvel identifiant. Attendez une confirmation, puis citez l'identifiant à quiconque le demande.

Malléabilité des transactions vs double dépense

La malléabilité déplace l'étiquette ; une double dépense déplace les fonds. Dans une transaction modifiée, les mêmes bitcoins atteignent la même adresse pour le même montant, et seul un logiciel qui a mémorisé l'ancien identifiant remarque que quelque chose s'est produit. Dans une double dépense, une transaction concurrente envoie ces bitcoins ailleurs et une version finit sans valeur. Confondre les deux apprend aux gens à se méfier des paiements confirmés, ce qui est la mauvaise leçon : un identifiant confirmé n'a jamais été mutable, car la malléabilité ne s'appliquait jamais qu'à une transaction en attente de confirmation.