Tous les six mois, le protocole Bitcoin Cash est mis à niveau afin d'être amélioré au niveau de sa capacité et son fonctionnement. Hier, mercredi 15 mai, c'était au tour des signatures de Schnorr d'être implémentées. Un autre changement mineur était également effectué pour permettre aux fonds présents sur les adresses P2SH SegWit (mises en place par Bitcoin, mais pas par Bitcoin Cash) d'être récupérés par les utilisateurs ayant confondu les deux réseaux.
Activée à 12:00 UTC (14:00 heure française), la mise à niveau s'est passée comme prévu et les premières transactions contenant des signatures de Schnorr ont pu être confirmées à partir du bloc 582 680. Dans le même temps, les mineurs ont pu procéder à la récupération des fonds depuis les adresses SegWit en envoyant ces fonds vers les adresses classiques correspondantes (exemple de transaction de ce type).
Cependant, quelque chose d'autre s'est produit après la mise à niveau : quelqu'un a attaqué le réseau en exploitant un bug trouvé dans Bitcoin ABC. Pour rappel, Bitcoin ABC est le client de référence de Bitcoin Cash, qui est actuellement utilisé par environ 60 % des nœuds du réseau selon coin.dance. Le bug ne concernait que Bitcoin ABC ; Bitcoin Unlimited, bchd et les autres n'ont pas été impactés.
Cette attaque a eu pour effet de paralyser le fonctionnement de Bitcoin Cash : les mineurs ont dû miner des blocs vides pendant plus de deux heures, laissant les transactions non confirmées s'accumuler dans la mempool. Un correctif a très rapidement été apporté par l'équipe de Bitcoin ABC, et a ensuite été déployé sur le réseau.
D'après BitMEX Research, un cafouillage aurait aussi provoqué un embranchement (fork) de la chaîne d'une longueur de deux blocs lors de la reprise de l'activité du réseau. Mais ceci n'aurait pas réellement été impactant.
Ainsi, l'exploitation du bug a créé plus de peur que de mal : les fonds des utilisateurs n'ont pas été compromis et le prix n'a pas chuté comme on aurait pu s'y attendre.
Quel était le bug ? Comme on l'a dit, ce bug n'a aucun rapport avec la mise à niveau implémentant les signatures de Schnorr et l'attaquant aurait très bien pu l'exploiter avant. Il provenait d'une ligne de code qui n'avait pas correctement été modifiée lors de la mise à niveau du 15 novembre 2018. Cette dernière mise à niveau introduisait, entre autres, le code opératoire OP_CHECKDATASIG.
Dans Bitcoin Cash, comme dans Bitcoin, outre la taille limite des blocs, il existe une limite d'opérations de signature (sigops) pour les blocs qui s'élève à 20 000. Le bug faisait que les opérations de signature contenues dans les transactions n'était pas bien comptabilisées lors de leur intégration dans la mempool : le comptage excluait en effet OP_CHECKDATASIG et OP_CHECKDATASIGVERIFY.
L'attaquant a donc envoyé un grand nombre de transactions utilisant OP_CHECKDATASIG de manière intensive. Comme ce code opératoire n'était pas pris en compte, les mineurs se sont mis à construire des blocs qu'ils constataient ensuite être invalides lors de la vérification par le logiciel. Par conséquent, le choix économique pour eux a été de miner des blocs « vides » ne contenant que la transaction de récompense, le temps que le correctif soit déployé.
Comme l'indique Amaury Séchet sur Reddit, la découverte de ce bug soulève un problème qui s'applique à Bitcoin ABC tout comme à Bitcoin Unlimited ou à Bitcoin Core : le problème de la dette technique. La dette technique est la complexité du code qui augmente à mesure qu'on lui ajoute des fonctionnalités sans le restructurer. Tout comme la dette économique, cette dette impose de payer des intérêts, ou bien sous la forme de difficulté de changement du code (un code complexe est plus difficile à changer qu'un code simple), ou bien sous la forme de bugs comme celui qui est intervenu hier.
Pour les systèmes traditionnels, cela constitue déjà une difficulté. Pour un système aussi sensible que Bitcoin, cette dette technique devient un problème central : en effet, puisque Bitcoin gère de la valeur, il ne peut pas subir de trop gros dysfonctionnements. C'est pourquoi les développeurs devraient se focaliser là-dessus avant d'intégrer de nouvelles fonctionnalités.
0 Comments