Bitcoin et son délai de confirmation minimum, explications

Bitcoin est souvent critiqué, entre autres choses, pour sa lenteur.

En effet, c’est un fait, les transactions réalisées sur la première couche du protocole sont loin d’être instantanées, puisqu’il faut attendre un certain temps avant qu’une transaction soit ajoutée dans un bloc, qui varie bien sûr en fonction de l’encombrement du réseau.

Pire, une transaction sur Bitcoin est d’autant moins instantanée que les frais que l’émetteur y attache sont faibles. Et pire encore, il ne suffit pas d’attendre que la transaction soit ajoutée dans un bloc pour être (relativement) certain de son immuabilité : il faut encore qu’elle soit confirmée, c’est-à-dire qu’un certain nombre de blocs supplémentaires aient été minés après le bloc contenant la transaction, rendant l’annulation de cette-dernière par une attaque par double-dépense virtuellement impossible.

La question qui se pose pour le destinataire — un magasin en ligne par exemple — est de savoir combien de blocs il doit attendre pour pouvoir considérer la transaction comme immuable. Autrement dit, à combien doit-il évaluer le temps de confirmation ? Trois blocs, soit une trentaine de minutes ? Quatre blocs ? Une heure ? Et est-ce que le client doit attendre tout ce temps dans le magasin ?

Disons-le d’emblée, il n’y a pas de réponse définitive et universelle à cette question, ne serait-ce que parce que cela dépend de l’aversion au risque du vendeur. En effet, un vendeur particulièrement risk averse pourrait décider d’attendre 24 heures, histoire de faire bonne mesure. Cela dépend aussi de caractéristiques propres au réseau, comme le hashrate par exemple. En effet, sur un réseau au hashrate bas, donc plus facilement attaquable, un vendeur averti choisira certainement un temps de confirmation plus long.

Cependant, ce nombre de confirmations au bout duquel on peut considérer une transaction comme finale est une métrique intéressante pour évaluer la vitesse de transaction réelle du réseau Bitcoin. C’est pourquoi nous nous efforcerons dans cet article de voir d’où vient le nombre canonique de 6 confirmations qu’on entend souvent, et comment on peut nuancer celui-ci pour parvenir à une mesure plus précise du nombre de confirmations requis pour se protéger en pratique d’une attaque par double-dépense.

Risque n°1 : l’attaque par double-dépense

Revenons brièvement sur la double-dépense, le déroulement d’une telle attaque, et ses conséquences.

Qu’est-ce que la double-dépense ?

Comme son nom l’indique, cette manipulation consiste à dépenser deux fois les mêmes bitcoins. Prenons l’exemple d’Alice qui achète une voiture sur internet. Elle paie le vendeur à l’aide d’une transaction de 1 bitcoin, le prix de la voiture. Mais, dans le même temps, elle envoie le même bitcoin vers une de ses autres adresses. Puisqu’elles impliquent le même bitcoin, une seule de ces deux transactions peut-être valide à la fois, ce qui signifie qu’à long terme, le réseau devra se décider pour l’une des deux et abandonner l’autre. Le but d’Alice est ici de faire croire suffisamment longtemps au vendeur que le paiement a bien eu lieu, grâce à une transaction apparaissant dans un bloc et confirmée par des blocs minés après celui contenant la transaction, puis de dévoiler au réseau une autre chaîne de blocs, de sa conception, plus longue que la chaîne officielle et où c’est la transaction d’Alice vers elle-même qui apparaît, et non pas celle vers le vendeur.

Déroulement de l’attaque

Pour espérer parvenir à ses fins, Alice doit disposer d’une part conséquente de la puissance de calcul total. Elle commence par diffuser sa transaction vers le vendeur et, pendant que celle-ci est ajoutée par les mineurs honnêtes dans le bloc suivant, elle mine de son côté un autre bloc, comprenant des transactions valides du mempool et sa transaction vers elle-même à la place de celle vers le vendeur.

Elle garde ce bloc secret. Ainsi, le vendeur voit de son côté apparaître le paiement. À partir de ce point, une course invisible s’engage entre Alice et les mineurs honnêtes du réseau : le but d’Alice est de réussir à doubler la chaîne principale (en terme de longueur) le plus vite possible (pour minimiser les coûts), mais après un certain nombre de blocs k, qui est le temps de confirmation au bout duquel le vendeur aura envoyé la voiture.

Dès qu’elle y parvient, elle publie sa chaîne de blocs et, celle-ci étant plus longue, le réseau n’a d’autre choix que de l’accepter, rejetant du même coup la chaîne précédente. Le paiement au vendeur, qui avait pourtant l’air confirmé, disparaît, en apparence d’un seul coup, remplacé par la transaction d’Alice vers elle-même. Alice a réussi son attaque par double-dépense.

Conséquences de l’attaque

Dans les faits, le vendeur ainsi arnaqué est souvent un exchange de cryptomonnaies.

Alice lui envoie des fonds, après un certain temps de confirmation (en nombre de blocs), l’exchange considère le transfert comme irréversible et Alice peut donc librement accéder à ces fonds sur l’exchange, les échanger contre une autre cryptomonnaie, rapatrier les fonds dans cette autre devise vers son wallet et publier, quand elle est prête, sa propre chaîne de blocs plus longue et ne contenant pas le transfert vers l’exchange.

Cela permet à l’attaquant de récupérer (voler, à vrai dire) de la valeur, et non pas un bien ou un service comme c’est le cas avec un vendeur plus “classique”.

Le lecteur s’en doute, réussir une telle attaque n’est pas chose aisée, notamment sur le réseau Bitcoin, particulièrement sécurisé grâce à ses quelques 100 EH/s (exahash par seconde, c’est à dire 100 milliards de milliards de hash par seconde).

Nous verrons dans la suite de cet article comment on peut évaluer le temps de confirmation minimum à patienter pour qu’une double-dépense soit suffisamment improbable pour être considérée comme impossible.

C’est par exemple la question que se posent les exchanges lorsqu’ils fixent leurs propres temps de confirmation, issus d’un compromis entre sécurité et rapidité d’exécution pour le client.

Une première méthode : évaluer la probabilité de réussite de la double-dépense

C’est la méthode la plus intuitive et la plus utilisée pour évaluer le temps de confirmation. Satoshi Nakamoto lui-même, dans le whitepaper de Bitcoin, estime une approximation de la probabilité pour une double-dépense de réussir, en fonction de la part du hashrate total détenue par l’attaquant (qui est par hypothèse inférieure à 51% du hashrate total).

On constate alors que pour un attaquant détenant 25% du hashrate (!), il suffit d’attendre 15 confirmations (environ 2 heures et demie) pour que la probabilité de subir une double-dépense soit inférieure à 0,1%. Pour une part de hashrate plus réaliste, comme par exemple quelque part autour des 10%, 5 blocs suffisent.

C’est de là que vient l’adage qui préconise d’attendre “entre 4 et 6 blocs” avant de considérer qu’une transaction est irréversible. L’exchange Kraken, par exemple, attend 6 confirmations avant de considérer un dépôt comme probablement irréversible, et il en est de même pour nombre de clients (au sens logiciel du terme) qui marqueront une transaction comme confirmée au bout de 4 à 6 confirmations.

Cette méthode consistant à évaluer la probabilité d’une double-dépense de réussir, en fonction du nombre de confirmations attendue, fournit une bonne approximation haute, et permet à chacun d’adapter son seuil de nombres de confirmations, en fonction notamment de son rapport au risque et de son estimation de la probabilité pour un attaquant de disposer d’un certain pourcentage du hashrate total. Elle peut cependant être nuancée en ajoutant une hypothèse supplémentaire.

Une seconde méthode : évaluer la profitabilité de la double-dépense pour l’attaquant

Cette hypothèse est la suivante : le but de l’attaquant effectuant une double-dépense est la profitabilité. On pourra l’admettre dans le cas général sans difficulté, les rares cas de figure où le profit n’est pas recherché étant des tentatives de démontrer la possibilité d’une telle attaque, ou bien de nuire à une cible précise.

Dans un papier paru en décembre 2019 et intitulé On Profitability of Nakamoto Double Spend (“De la profitabilité de la double-dépense de Nakamoto”), les chercheurs Cyril Grunspan et Ricardo Pérez-Marco font donc implicitement cette hypothèse que l’attaquant a pour objectif de gagner de l’argent grâce à sa double-dépense, ce qui les amène à étudier la profitabilité de l’attaque.

Pour ce faire, ils commencent par définir une stratégie pour l’attaquant, qui diffère légèrement de celle imaginée par Nakamoto dans le whitepaper de Bitcoin.

En effet, ce-dernier imagine un attaquant qui, disposant d’un hashrate compris entre 0 et 50% de la puissance de calcul totale, continuerait à attaquer jusqu’à avoir réussi son attaque. Il existe donc dans cette stratégie une probabilité positive pour l’attaquant de faire complètement faillite, s’il s’obstine à tenter de dépasser la chaîne principale alors que celle-ci a pris une avance trop considérable pour qu’il soit possible de la rattraper.

La stratégie proposée par les chercheurs, et baptisée “stratégie A-Nakamoto” (A-Nakamoto strategy) consiste donc à définir un seuil A tel que, si l’attaquant se retrouve A blocs derrière la chaîne principale, il abandonne. L’attaquant peut alors définir ce nombre A de blocs, suivant ses ressources, sachant qu’on fait par simplicité l’hypothèse que ce nombre sera supérieur au nombre de confirmations attendu par la victime de l’attaque.

Reste encore à définir ce que l’on entend par “profitable” lorsqu’on parle d’une attaque par double-dépense ? Que le larcin de l’attaque soit supérieur au coût (en machines, énergie, etc.) nécessaire pour la mener ? Cela complique inutilement le problème en ajoutant des inconnues supplémentaires (le prix du hardware, le prix de l’électricité, etc.).

Il suffit pour définir une attaque comme rentable que cette dernière rapporte plus à l’attaquant que s’il avait miné honnêtement. En effet, l’une des forces de Bitcoin, et qui contribue grandement à sa sécurité, est que les intérêts des mineurs sont a priori alignés avec l’intérêt commun, puisqu’ils sont incités à miner honnêtement au travers des récompenses de bloc et des frais de transaction.

Les résultats auxquels parviennent les chercheurs au terme du papier (qui passe par l’étude de la stratégie A-Nakamoto et de l’étude du déroulé de l’attaque, en fonction de paramètres comme le seuil d’abandon A, du hashrate relatif de l’attaquant ou encore du temps de confirmation attendu par le vendeur) sont assez éloignés de ceux auxquels était parvenu Nakamoto en ne prenant en compte que la probabilité de réussite de l’attaque.

En effet, ils parviennent à la conclusion que, si le vendeur attend deux confirmations (donc un bloc de plus que celui où sa transaction figure, pour une double-dépense d’une coinbase (12,5 BTC actuellement) et pour un seuil d’abandon supérieur ou égal à 10, la double-dépense est toujours moins rentable que le minage honnête, quel que soit le hashrate relatif de l’attaquant (par hypothèse inférieur à 51%). Cela exclut également de facto la stratégie envisagée par Nakamoto dans le whitepaper, où il n’y a tout simplement pas de seuil d’abandon (c’est-à-dire que le seuil d’abandon tend vers l’infini). Pour des seuils d’abandon A réalistes, entre 3 et 5 blocs, et avec le même temps de confirmation et la même valeur transactée, la double-dépense ne devient rentable qu’entre 40% et 45% de hashrate relatif.

Il apparaît donc ainsi que pour une transaction d’un montant “courant” (la valeur prise dans l’étude est d’une coinbase, soit 125 000$ au cours actuel, tout de même, mais qui peut le plus peut le moins), une à deux confirmations suffisent en pratique à se prémunir d’une double-dépense. Dans les faits, pour une transaction telle qu’on les expérimente quotidiennement, de quelques centaines à quelques milliers d’euros, on peut donc sereinement considérer une transaction comme finale dès lors qu’elle est inscrite dans un bloc (une seule confirmation).

Donc il suffit d’attendre une seule confirmation ?

Oui, et non. Oui, car aussi contre-intuitif que cela puisse paraître lorsqu’on est habitué à attendre plusieurs blocs pour espérer considérer une transaction comme probabilistiquement (et probablement) finale, le réseau Bitcoin est aujourd’hui suffisamment sécurisé pour qu’une transaction de valeur courante puisse être considérée comme immuable dès son ajout dans un bloc. Il faut cependant garder à l’esprit que les stratégies d’attaque étudiées par Nakamoto et Grunspan et Pérez-Marco sont assez “simplistes” en comparaison du spectre des stratégies possibles. On peut par exemple penser au pré-minage par l’attaquant d’un certain nombre de blocs avant le début de l’attaque, ou encore de l’utilisation simultanée d’une attaque par éclipse pour cacher à la victime la transaction de double-dépense et lui faire croire qu’elle a bien reçu les bitcoins promis.

Enfin, et il est important d’insister sur ce point, l’étude pointe seulement que les utilisateurs “standards” de Bitcoin, qui reçoivent des transactions d’un montant inférieur ou égal à une coinbase (soit, rappelons-le, 12,5 bitcoins actuellement) n’ont, en pratique, pas besoin d’attendre 6 confirmations pour considérer sereinement la transaction comme finale, car la double-dépense n’est de toute façon pas profitable pour un montant aussi “faible”. Pour de plus gros volumes, ou pour des utilisateurs aussi stratégiques que les exchanges, la prudence reste donc de mise, et les 6 confirmations attendues par Kraken (par exemple) ne semblent pas de trop pour garantir la sécurité financière de ces places d’échanges.

En conclusion

En quelques points, que faut-il retenir de cet article ?

• La métrique du nombre de confirmations nécessaires pour pouvoir considérer une transaction comme finale est intéressante car c’est une mesure pertinente de la capacité pour Bitcoin à être utilisé, dès le niveau du protocole, pour réaliser des transactions en sécurité (même si cette métrique oblitère le temps d’attente avant l’ajout de la transaction dans un bloc) ;
• Cette mesure est globalement surévaluée dans la littérature, où seule la probabilité de réussite de l’attaque par double-dépense est prise en compte, et non pas sa profitabilité ;
• En prenant en compte la profitabilité de l’attaque, on parvient à la conclusion que dans la pratique, la plupart des transactions peuvent être considérées comme finales dès une ou deux confirmations.