Quand vous envoyez une photo à un ami, vous la gardez aussi. De l’argent qui n’existe que sous forme de données a le même défaut : sans règle supplémentaire, on pourrait envoyer la même pièce numérique à deux personnes tout en la conservant. C’est le problème de la double dépense (en anglais, double spending), et toute monnaie électronique a dû le résoudre. Bitcoin le résout avec un registre public qui range chaque paiement dans l’ordre. La défense est solide, avec deux points faibles : les minutes qui précèdent l’inscription d’un paiement dans ce registre, et les rares moments où le réseau garde deux versions de celui-ci.
L’un de ces moments date de la nuit du 11 mars 2013. Une mise à jour du logiciel a coupé le réseau Bitcoin en deux sans que personne l’ait voulu, et pendant quelques heures deux versions du registre ont grandi côte à côte. Un utilisateur a, selon son propre récit sur le forum Bitcointalk, payé 211,9 bitcoins, soit environ 10 000 dollars à l’époque, au service de paiement OKPay sur l’une des versions, tandis qu’une seconde transaction renvoyant les mêmes pièces vers lui-même entrait dans l’autre. Quand les mineurs ont ramené le réseau à une seule version, celle qui l’a emporté ne contenait pas son paiement à OKPay. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il s’est tout simplement volatilisé.
L’analyse après coup de cette scission, le BIP 50, rédigée par les développeurs de Bitcoin (en anglais), confirme « at least one large double spend » (au moins une double dépense de grande taille) et précise qu’elle a été faite par quelqu’un qui cherchait à voir si c’était possible et qu’elle « was not intended to be malicious » (n’avait pas de visée malveillante). C’est la double dépense la mieux connue d’un paiement confirmé sur Bitcoin lui-même. Elle montre aussi la règle autour de laquelle tourne toute cette leçon : quand deux paiements dépensent les mêmes pièces, un seul survit, et tout dépend de celui que le réseau retient.
Qu’est-ce que la double dépense ?
La double dépense est le risque qu’une même unité de monnaie numérique soit dépensée plusieurs fois, parce qu’un fichier ou un message se copie sans aucun coût. Tout système d’argent électronique doit garantir que, lorsque deux paiements utilisent les mêmes fonds, un seul compte, et que tout le monde s’accorde sur lequel.
Pourquoi une pièce numérique se copie et pas un billet
Un billet est un objet physique. Quand vous le tendez au commerçant, vous ne l’avez plus, et personne n’a besoin de consulter un registre pour le savoir. Une pièce numérique est une suite d’octets, et les octets se copient autant de fois qu’on veut, gratuitement. Envoyez un « fichier pièce » par courriel : il reste sur votre ordinateur, prêt à repartir.
Les signatures numériques n’y changent rien. Une signature prouve que le propriétaire a approuvé un paiement ; elle ne dit pas s’il en a déjà approuvé un autre portant sur la même pièce au profit de quelqu’un d’autre. Deux transactions parfaitement valides, parfaitement signées, peuvent dépenser les mêmes fonds. Le destinataire de l’une ne peut pas voir, en l’examinant seule, que l’autre existe.
Ne confondez pas avec le « double paiement » par carte bancaire, que les internautes cherchent aussi : il s’agit là d’un commerçant ou d’une banque qui débite deux fois un même achat, un litige d’une autre nature. Ici, c’est la même monnaie qui est dépensée deux fois, volontairement, par celui qui la détient.
La double dépense est une affaire d’ordre, pas de faux
L’astuce n’est donc pas d’empêcher quiconque d’écrire un second paiement : n’importe qui peut en écrire un. La vraie tâche consiste à décider lequel de deux paiements en conflit est arrivé le premier, et à faire accepter cette décision par tous. Satoshi Nakamoto a énoncé la règle simplement dans la section 2 du livre blanc de Bitcoin (en anglais) : « the earliest transaction is the one that counts, so we don’t care about later attempts to double-spend », c’est-à-dire que la première transaction est celle qui compte et que les tentatives ultérieures de double dépense n’intéressent pas le système.
La même section désigne la difficulté : « The only way to confirm the absence of a transaction is to be aware of all transactions. » Pour savoir qu’une pièce n’a pas déjà été dépensée, il faut un registre complet et partagé de tous les paiements et de leur ordre. Pendant des décennies, la seule manière connue de bâtir ce registre consistait à le confier à un tiers de confiance.
Avant Bitcoin, un teneur de registre central tranchait chaque litige
Banques et réseaux de cartes : un registre, un employé
Votre compte bancaire n’est pas un tas de pièces. C’est une ligne dans une base de données que contrôle la banque. Quand vous payez par carte ou par virement, la banque ou le réseau de cartes inscrit le débit, vérifie votre solde et refuse le second paiement si l’argent n’est plus là. Une double dépense est impossible dans ce montage, parce qu’un seul employé voit chaque demande et les range dans l’ordre. Le prix à payer, c’est de dépendre de lui : il peut geler, annuler ou refuser un paiement, et ses écritures sont la seule vérité.
La monnaie de Chaum : vérification en ligne, puis chasse aux tricheurs après coup
Les premières tentatives sérieuses d’argent numérique ont gardé un teneur de registre. Dans l’eCash de David Chaum, une banque ou un « hôtel des monnaies » (mint) émettait les pièces et contrôlait chacune d’elles au moment de la dépenser, en refusant toute pièce déjà vue. Notre leçon sur la monnaie numérique avant Bitcoin raconte cette histoire, avec Hashcash, b-money et bit gold. Ce qui compte ici, c’est ce qui se passait quand l’hôtel des monnaies était hors ligne : le système ne pouvait pas empêcher une double dépense, seulement démasquer le tricheur ensuite. Hal Finney, qui expliquait en 1993 le schéma hors ligne de Chaum, résumait sa promesse ainsi : « Anonymity as long as you don’t cheat, and double-spenders get caught » (l’anonymat tant que vous ne trichez pas, et les auteurs de double dépense se font prendre), dans « Detecting Double-Spending » (en anglais).
Le livre blanc de Nakamoto décrit ce modèle et sa faiblesse en une phrase : une solution courante est « to introduce a trusted central authority, or mint, that checks every transaction for double spending », soit une autorité centrale de confiance qui contrôle chaque transaction. Tout dépend alors de l’entreprise qui fait tourner cet hôtel des monnaies, chaque paiement devant passer par elle, « just like a bank » (comme pour une banque). Le but de Bitcoin était de garder la protection et de supprimer l’intermédiaire.
Comment Bitcoin résout la double dépense sans autorité centrale
Le résumé du livre blanc annonce l’ambition en une ligne : « We propose a solution to the double-spending problem using a peer-to-peer network » (nous proposons une solution au problème de la double dépense grâce à un réseau pair à pair). La solution comporte plusieurs éléments, chacun simple en lui-même. Notre guide sur le livre blanc de Bitcoin expliqué résume tout le document ; cette leçon ne suit que le fil de la double dépense.
Chaque paiement est annoncé à tout le monde
Au lieu d’envoyer un paiement à un seul employé, un portefeuille Bitcoin le diffuse à l’ensemble du réseau d’ordinateurs qui font tourner le logiciel, qu’on appelle les nœuds. Chaque nœud le transmet à d’autres. La section 2 du livre blanc demande que les transactions soient « publicly announced » (annoncées publiquement) pour que les participants s’accordent sur une histoire unique de l’ordre dans lequel elles ont été reçues. Dès qu’un paiement est public, un second paiement des mêmes pièces l’est aussi, et le conflit se voit.
Les blocs rangent les paiements dans un ordre public
Voir un conflit ne suffit pas : selon leur place dans le réseau, les nœuds peuvent apprendre les deux paiements dans un ordre différent. La section 3 du livre blanc commence ainsi : « The solution we propose begins with a timestamp server » (la solution que nous proposons commence par un serveur d’horodatage). Bitcoin regroupe les paiements en blocs, et chaque bloc contient l’empreinte du précédent, si bien que les blocs forment une chaîne dans le temps. Un paiement inclus dans un bloc occupe une position dans cette chaîne ; un paiement concurrent ne peut venir que plus tard, et le plus tardif perd.
C’est ce que signifie une confirmation. Un paiement reçoit sa première confirmation quand il est inclus dans un bloc, puis une de plus chaque fois qu’un nouveau bloc s’ajoute par-dessus. Plus il est enfoui profondément, plus il est difficile à déplacer.
Les nœuds refusent toute pièce déjà dépensée
Bitcoin ne tient pas de soldes. Il suit des sorties non dépensées : chaque paiement consomme entièrement des sorties antérieures et en crée de nouvelles, comme l’explique la leçon précédente sur les modèles UTXO et de comptes. Chaque nœud conserve la liste des sorties encore non dépensées. Quand une transaction tente de dépenser une sortie qui n’y figure plus, le nœud la rejette, et un bloc qui la contient est invalide pour tout nœud honnête. Une double dépense n’est donc pas un tour de comptabilité : c’est une lutte pour savoir laquelle de deux transactions d’apparence valide entre la première dans l’histoire commune.
Deux blocs à la fois : la chaîne qui porte le plus de travail l’emporte
Il arrive que deux mineurs trouvent un bloc presque au même instant, et pendant un court moment le réseau détient deux versions de la dernière page. Notre leçon sur le fonctionnement d’une blockchain montre comment cela se règle : les mineurs continuent, une branche prend de l’avance et tous les nœuds basculent dessus. La règle du livre blanc : « Nodes always consider the longest chain to be the correct one and will keep working on extending it » (les nœuds considèrent toujours la chaîne la plus longue comme la bonne et continuent de l’allonger).
« La plus longue » demande de la précision. Dans la section 4, le livre blanc dit que la décision majoritaire est représentée par la chaîne « which has the greatest proof-of-work effort invested in it », celle dans laquelle l’effort de preuve de travail est le plus grand. C’est donc la chaîne qui a accumulé le plus de travail, pas celle qui compte le plus de blocs, et c’est bien ce que compare le logiciel Bitcoin Core. Produire ce travail coûte de l’électricité et du matériel, et c’est pourquoi réécrire l’histoire d’une blockchain a un prix.
Quand les nœuds passent d’une branche à l’autre, les blocs de la branche abandonnée disparaissent. Les ingénieurs parlent de réorganisation, ou reorg. Tout paiement qui ne figurait que dans la branche abandonnée perd ses confirmations, et si un paiement concurrent se trouve dans la branche gagnante, le premier ne pourra jamais être inclus. Une réorganisation est le moment où une double dépense devient réelle.
Ce qu’un tricheur peut faire et ne peut pas faire
La section 11 du livre blanc est précise sur les limites d’un tricheur, même doté d’une grande puissance de calcul. Elle dit : « An attacker can only try to change one of his own transactions to take back money he recently spent. » Autrement dit, il ne peut que tenter de modifier l’une de ses propres transactions pour récupérer de l’argent qu’il a dépensé récemment. Il ne peut pas créer des pièces à partir de rien ni dépenser des pièces qui n’ont jamais été à lui, car les nœuds honnêtes rejettent les transactions invalides quelle que soit la chaîne. Le danger est étroit : un paiement récent de l’attaquant, annulé après que la victime a remis la marchandise ou l’argent.
Cinq manières de tenter de dépenser deux fois
La page du wiki Bitcoin sur les transactions irréversibles (en anglais) recense les attaques classiques par double dépense. Elles diffèrent par le moment où elles frappent et par la puissance dont l’attaquant a besoin. Certaines n’exigent qu’un portefeuille. La plus forte demande du hashrate, la puissance de calcul consacrée au minage, c’est-à-dire la ressource qui décide quelle version du registre l’emporte.
| Attaque | Quand elle fonctionne | Qui peut la tenter | Parade principale |
|---|---|---|---|
| Attaque par course (race attack) | Paiement accepté sans aucune confirmation | N’importe qui avec un portefeuille | Attendre au moins une confirmation |
| Remplacement par les frais (RBF) | Paiement accepté sans aucune confirmation | N’importe qui avec un portefeuille | Ne jamais considérer un paiement non confirmé comme réglé |
| Attaque de Finney | Paiement accepté sans aucune confirmation | Un mineur qui trouve des blocs | Attendre des confirmations |
| Vector76 | Paiement accepté après une confirmation | Un mineur bien placé dans le réseau | Attendre plusieurs confirmations |
| Attaque des 51 % (majorité) | Même après de nombreuses confirmations | Celui qui contrôle la majorité du hashrate | Plus de confirmations en relèvent le coût ; les petites chaînes en exigent bien davantage |
Attaque par course : deux paiements en conflit au même moment
La tentative la plus simple n’exige aucun équipement particulier. Le tricheur envoie un paiement à un commerçant et, presque au même moment, une seconde transaction qui dépense les mêmes pièces vers sa propre adresse, diffusée au plus grand nombre possible de nœuds et de mineurs. Si la seconde atteint les mineurs en premier, elle entre dans un bloc et le paiement du commerçant est écarté. Selon le wiki Bitcoin, le commerçant peut réduire le risque, par exemple en se connectant à des nœuds bien reliés, mais « the risk cannot be eliminated » (le risque ne peut pas être éliminé). L’attaque ne marche que contre quelqu’un qui accepte un paiement avant sa confirmation.
Remplacement par les frais : quand l’émetteur a le droit d’échanger un paiement
Le remplacement par les frais (RBF, pour replace-by-fee) est une fonction normale, pas une attaque : elle permet à un émetteur de remplacer une transaction non confirmée par une nouvelle version qui paie davantage de frais, en général pour débloquer un paiement. Notre guide sur le fonctionnement des transactions crypto montre comment s’y prendre. Le piège, pour le destinataire, c’est que la nouvelle version peut aussi envoyer l’argent ailleurs.
Au début, le remplacement était facultatif. Avec le BIP 125, attribué en décembre 2015, une transaction signalait qu’elle pouvait être remplacée, et la proposition notait que les destinataires peuvent choisir de ne pas la traiter comme un paiement avant sa confirmation. Cette distinction a disparu. Bitcoin Core 28.0, publié le 2 octobre 2024, a fait du remplacement complet le réglage par défaut, et Bitcoin Core 29.0, publié le 14 avril 2025, a supprimé l’option qui permettait de le désactiver. Sur Bitcoin Core, le logiciel que font tourner la plupart des nœuds, tout paiement non confirmé peut être remplacé par un paiement concurrent mieux payé, qu’il ait signalé ou non cette possibilité. C’est une politique de relais, pas une règle de consensus : les mineurs peuvent utiliser d’autres logiciels, mais un commerçant ne peut pas compter là-dessus.
Attaque de Finney : un mineur cache un bloc
Le 13 février 2011, Hal Finney a décrit sur le forum Bitcoin une ruse à la portée d’un mineur. Son message commence par « Suppose the attacker is generating blocks occasionally » (supposons que l’attaquant génère des blocs de temps en temps). Le mineur place dans un bloc qu’il a trouvé mais pas encore publié un transfert entre deux de ses propres adresses. Il paie ensuite un commerçant avec les mêmes pièces. Si le commerçant remet la marchandise sans attendre, le mineur publie son bloc, qui dépense déjà ces pièces, et le paiement au commerçant devient invalide. Le scénario porte désormais le nom de Finney. Il demande de la puissance de minage et un peu de chance dans le moment choisi, et, comme l’attaque par course, il ne vient à bout que d’une acceptation sans confirmation.
Vector76 : une confirmation ne suffit pas toujours
L’attaque Vector76 mêle les deux précédentes. L’attaquant mine un bloc contenant un dépôt, ne l’envoie qu’à sa victime, typiquement une plateforme d’échange, et laisse le reste du réseau bâtir sur un bloc contenant une transaction concurrente. La victime voit brièvement une confirmation, crédite le dépôt et laisse l’attaquant retirer ses fonds ; quand son nœud rattrape le reste du réseau, le dépôt s’évanouit. L’attaquant sacrifie une récompense de bloc pour y parvenir, ce qui n’a de sens que contre un gros retrait, rapide. Une confirmation vaut bien mieux que zéro, mais ce n’est pas une garantie.
Attaque des 51 % : réécrire l’histoire récente
La version sérieuse est celle que modélise le livre blanc, et celle que cherchent les internautes sous le nom d’attaque des 51 % sur une blockchain. L’attaquant mine en secret une branche où son paiement à la victime n’a jamais eu lieu, attend que la victime livre, puis publie sa branche. Si elle porte plus de travail accumulé que la branche publique, tous les nœuds basculent dessus, et le paiement de la victime disparaît. Celui qui contrôle plus de la moitié du hashrate du réseau peut finir par gagner cette course, d’où le nom d’attaque des 51 %. En dessous de la moitié, les chances de l’attaquant s’effondrent à chaque confirmation que la victime attend.
Les chiffres de Nakamoto lui-même, dans la même section 11, donnent la probabilité que l’attaquant rattrape son retard, selon sa part du hashrate et le nombre de confirmations attendues par la victime :
| Part du hashrate de l’attaquant | Confirmations attendues | Probabilité de rattrapage (livre blanc) |
|---|---|---|
| 10 % | 1 | 0,2045873 |
| 10 % | 5 | 0,0009137 |
| 10 % | 6 | 0,0002428 |
| 30 % | 5 | 0,1773523 |
| 30 % | 10 | 0,0416605 |
| 30 % | 24 | moins de 0,001 (deuxième tableau du livre blanc) |
| 30 % | 50 | 0,0000006 |
Concrètement : avec 10 % du hashrate, un attaquant face à six confirmations réussit environ 2,4 fois sur 10 000 tentatives dans le modèle du livre blanc. Avec 30 %, cinq confirmations lui laissent encore près de 18 % de chances, et la victime doit attendre 24 confirmations pour ramener le risque sous 0,1 %. Des analyses ultérieures, fondées sur d’autres hypothèses, donnent des chiffres plus élevés : considérez ce tableau comme le modèle simplifié du livre blanc, pas comme une prévision précise. Au-dessus de 50 %, aucun nombre de confirmations ne protège la victime ; le wiki écrit « No amount of confirmations can prevent this attack » (aucun nombre de confirmations ne peut empêcher cette attaque), même si attendre augmente le coût pour l’attaquant. Une prochaine leçon de Coindaro sur les attaques des 51 % ira plus loin dans leur économie.
Doubles dépenses réelles, de 2013 à 2020
Des doubles dépenses ont bien eu lieu, et le bilan dessine un schéma net : une sur Bitcoin, lors d’une scission accidentelle, et les autres sur des chaînes à preuve de travail plus petites, dont on pouvait louer la puissance de calcul. Notre guide sur la question de savoir si une blockchain peut être piratée détaille les cas de Bitcoin Gold et d’Ethereum Classic ; voici la version courte.
| Date | Chaîne | Ce qui s’est passé | Montant rapporté (à l’époque) | Source |
|---|---|---|---|---|
| 11-12 mars 2013 | Bitcoin | Scission accidentelle entre la version 0.8 et des nœuds plus anciens ; un paiement de 211,9 BTC à OKPay annulé | environ 10 000 dollars, d’après le récit de l’utilisateur | BIP 50 ; fil de discussion de l’utilisateur |
| À partir du 18 mai 2018 | Bitcoin Gold | Un attaquant disposant de la majorité du hashrate a dépensé deux fois des dépôts sur des plateformes d’échange | plus de 388 000 BTG passés par l’adresse de l’attaquant ; plus de 18 millions de dollars, estimation de BleepingComputer | BleepingComputer, 24 mai 2018 |
| À partir du 5 janvier 2019 | Ethereum Classic | Réorganisations profondes avec doubles dépenses, détectées par Coinbase | 219 500 ETC dans 13 doubles dépenses, environ 1,1 million de dollars | Infosecurity Magazine, 8 janvier 2019 |
| Août 2020 | Ethereum Classic | Trois réorganisations en un mois, de 3 693, environ 4 000 et plus de 7 000 blocs | non précisé dans la source | The Block, 31 août 2020 |
Mars 2013 n’était pas une attaque. Selon le BIP 50, un bloc accepté par la version 0.8 a été rejeté par certains nœuds plus anciens, le camp de la 0.8 détenait environ 60 % de la puissance de hachage, et deux gros pools sont revenus à l’ancienne version pour mettre fin à la scission. La double dépense a fonctionné alors même que les deux camps avaient vu les transactions dans le même ordre, très probablement parce que les mempools (les files d’attente de transactions non confirmées) ont été vidés au redémarrage des nœuds des pools. Le récit de l’utilisateur figure dans un fil de discussion du 12 mars 2013, auquel renvoie l’analyse après coup. D’après lui, le paiement à OKPay était un dépôt sur son compte de la plateforme d’échange BTC-e, et les deux transactions en conflit ont été minées à la même hauteur, le bloc 225 446, une sur chaque branche.
Bitcoin Gold, une scission de Bitcoin datant de 2017, a été frappé par un attaquant qui contrôlait plus de la moitié de sa puissance de minage. D’après BleepingComputer (en anglais), les attaques ont commencé le 18 mai 2018, l’attaquant déposait des pièces sur des plateformes d’échange tout en envoyant les mêmes pièces vers son propre portefeuille, et plus de 388 000 BTG sont passés par son adresse, ce qui laissait penser, selon le site, à un gain de plus de 18 millions de dollars. Les cibles étaient les plateformes d’échange, pas les détenteurs : aucun utilisateur n’avait perdu d’argent, selon l’article.
Ethereum Classic, la chaîne qui a gardé l’histoire d’origine d’Ethereum après 2016, a été attaquée en janvier 2019. Coinbase a d’abord détecté une réorganisation profonde contenant une double dépense le 5 janvier, puis 12 autres doubles dépenses, pour un total de 219 500 ETC, soit environ 1,1 million de dollars à l’époque, selon Infosecurity Magazine (en anglais). En août 2020, la chaîne a subi trois réorganisations en un mois, la dernière de plus de 7 000 blocs de profondeur, soit environ deux jours de minage selon l’exploitant de pool Bitfly, d’après The Block (en anglais).
La leçon de ces cas tient à la taille. Réécrire la chaîne de Bitcoin reviendrait à dépasser le hashrate du plus grand réseau à preuve de travail. Sur une chaîne dont tout le hashrate peut se louer pour quelques heures, la même attaque peut coûter moins cher que les pièces qu’elle dérobe. Après l’attaque contre Bitcoin Gold, les plateformes d’échange ont relevé le nombre de confirmations exigées pour les dépôts, a rapporté BleepingComputer.
Pourquoi six confirmations, et pourquoi une suffit pour un café
Six confirmations, soit environ une heure en moyenne, sont devenues la marge de sécurité habituelle de Bitcoin. La leçon sur le mempool et les frais de transaction explique d’où vient cette convention et comment un paiement passe de la diffusion au bloc. Le tableau du livre blanc montre pourquoi elle est raisonnable : face à un attaquant qui détient 10 % du hashrate, six blocs ramènent le risque à 0,024 % dans le modèle du document.
Six est une convention, pas une règle du protocole. Chaque destinataire fixe son propre seuil, et le bon nombre dépend de deux choses : le montant en jeu et le hashrate de la chaîne. Kraken, par exemple, crédite les dépôts de bitcoins après trois confirmations, d’après sa page d’aide sur les délais de traitement des dépôts mise à jour le 22 octobre 2026. Le vendeur d’une voiture peut attendre plus de six confirmations. Un café qui vend un expresso à 4 dollars peut accepter le risque de zéro confirmation, parce que la perte est faible et que le tricheur doit se présenter au comptoir.
Sur les chaînes à preuve de travail plus petites, le même nombre de blocs achète beaucoup moins de sécurité, car leur production coûte bien moins cher. C’est pourquoi une plateforme d’échange peut demander beaucoup plus de confirmations sur une telle chaîne que sur Bitcoin.
Transaction bitcoin non confirmée : le vrai risque du commerçant
Une transaction bitcoin non confirmée est une promesse annoncée, pas un paiement réglé. Entre le moment où un portefeuille affiche « reçu » et le premier bloc, l’émetteur peut encore tenter une attaque par course ou, avec les logiciels de nœud par défaut d’aujourd’hui, diffuser simplement un remplacement qui paie davantage de frais. À 9 h 50 UTC le 7 novembre 2026, mempool.space recommandait 2 satoshis par octet virtuel pour la confirmation la plus rapide : un remplacement pouvait donc coûter très peu à un tricheur.
Les chercheurs ont donné l’alerte tôt. Dans un article de 2012, « Two Bitcoins at the Price of One? » (en anglais), Ghassan Karame, Elli Androulaki et Srdjan Čapkun sont partis d’un restaurant de restauration rapide qui acceptait le bitcoin, et ont montré que des doubles dépenses contre de tels paiements rapides pouvaient être montées à faible coût sur le logiciel Bitcoin de l’époque.
Pour un commerçant, les règles pratiques tiennent en peu de lignes :
- Considérer un paiement à zéro confirmation comme non encore reçu, sauf si le montant est de ceux que l’on est prêt à perdre.
- N’expédier la marchandise ou ne libérer les fonds qu’après le nombre de confirmations choisi pour ce montant.
- Exiger plus de confirmations sur une chaîne à faible hashrate que sur Bitcoin.
- Pour les petits paiements instantanés, utiliser un système conçu pour eux, comme un réseau de canaux de paiement tel que Lightning, plutôt que des transactions non confirmées sur la chaîne.
Ethereum et les autres chaînes à comptes : le nonce fait le travail
Ethereum n’utilise pas de sorties non dépensées. Il tient un solde pour chaque compte, et chaque transaction porte un nonce, que la page d’ethereum.org sur les transactions (en anglais) décrit comme « a sequentially incrementing counter which indicates the transaction number from the account », un compteur qui s’incrémente en séquence et indique le numéro de la transaction du compte. La première transaction d’un compte utilise le nonce 0, la suivante le nonce 1, et ainsi de suite.
Le nonce joue le rôle que joue la « sortie déjà dépensée » sur Bitcoin. Deux transactions du même compte avec le même nonce sont en conflit, et une seule des deux pourra jamais être incluse dans la chaîne. La leçon sur les modèles UTXO et de comptes montre l’envers de cette règle, le nonce bloqué qui retient toutes les transactions suivantes.
La logique du zéro confirmation est la même que sur Bitcoin. Une transaction Ethereum en attente peut être remplacée par une autre avec le même nonce et des frais plus élevés ; les règles par défaut de Geth, un client Ethereum très répandu, exigent des frais supérieurs d’au moins 10 %. Un paiement encore en attente n’est pas un paiement.
Ethereum a aussi refermé une porte qui s’était ouverte lors de la scission de la chaîne en 2016. Avec l’EIP-155, une transaction signe l’identifiant de la chaîne à laquelle elle est destinée, et ne peut donc pas être copiée et rejouée sur une autre chaîne qui partage le même historique. Depuis son passage à la preuve d’enjeu, Ethereum marque aussi des blocs comme finaux après un délai, sujet d’une prochaine leçon sur la finalité et les réorganisations.
Solana : un blockhash récent qui expire
Solana prend un autre chemin. Chaque transaction doit inclure un blockhash récent, une référence à un bloc récent, et les validateurs ne l’acceptent que pendant un temps limité : le SDK de Solana (en anglais) fixe l’âge maximal à 150 blockhashes récents, soit une minute ou moins à la vitesse de Solana. Une transaction trop ancienne est rejetée, si bien qu’un paiement signé ne peut pas traîner des jours en attendant d’être rejoué. Dans cette fenêtre, les validateurs gardent aussi la trace des signatures déjà traitées et refusent la même transaction une seconde fois. Quant aux dépenses en conflit issues d’un même compte, elles sont simplement ordonnées par le validateur qui produit le bloc.
Preuve d’enjeu : la « double signature » est un autre genre de double
Sur les chaînes à preuve d’enjeu, le mot « double » apparaît dans un autre sens. Les validateurs, qui immobilisent des pièces pour participer, sont punis par une destruction partielle de leur mise (slashing) s’ils signent deux versions contradictoires de l’histoire. La page d’ethereum.org sur les récompenses et pénalités (en anglais) liste trois fautes : proposer et signer deux blocs différents pour le même créneau, attester un bloc qui en « entoure » un autre, et le double vote, c’est-à-dire attester deux candidats pour le même bloc.
Ce n’est pas un utilisateur qui paie deux fois. C’est un validateur qui cherche à soutenir deux histoires, exactement ce dont aurait besoin une double dépense profonde. Le slashing brûle une partie de la mise du validateur et l’exclut, si bien que la tentative est à la fois coûteuse et imputable à son auteur. Un utilisateur qui envoie deux paiements en conflit n’est pas sanctionné de la sorte : un des paiements échoue, simplement.
Pas de rétrofacturation en crypto : comparaison avec la carte et la banque
L’envers de la conception de Bitcoin, c’est qu’un paiement confirmé n’a plus d’employé capable de l’annuler. Le livre blanc le présente comme un atout pour les vendeurs : « Transactions that are computationally impractical to reverse would protect sellers from fraud », des transactions pratiquement impossibles à annuler protégeraient les vendeurs de la fraude. Pour un acheteur qui a payé un escroc, cela veut dire que l’argent est perdu. La Federal Trade Commission américaine l’écrit sans détour dans ses conseils aux consommateurs sur les arnaques crypto (en anglais) : « Cryptocurrency payments typically are not reversible. »
Comparons avec ce que prévoit le droit français pour un paiement par carte. D’après la page de l’Institut national de la consommation (INC) « Comment contester une opération de paiement par carte bancaire ? », vérifiée le 21 novembre 2024 et fondée sur le Code monétaire et financier, un paiement effectué dans l’Espace économique européen peut être contesté dans les 13 mois suivant le débit (article L. 133-24). Hors de l’Espace économique européen, le délai n’est que de 70 jours, extensible par contrat jusqu’à 120 jours. Une opération non autorisée doit être remboursée immédiatement (article L. 133-18), et c’est à la banque, non au client, de prouver que l’opération a été correctement authentifiée (article L. 133-23). Le remboursement n’est pas dû si le titulaire a manqué à ses obligations de manière intentionnelle ou par négligence grave.
Les États-Unis et le Royaume-Uni offrent des protections du même ordre. Aux États-Unis, la Regulation Z plafonne à 50 dollars la responsabilité du titulaire d’une carte de crédit en cas d’utilisation non autorisée, et une erreur de facturation signalée dans les 60 jours suivant le relevé doit être réglée en deux cycles de facturation, et jamais en plus de 90 jours. Au Royaume-Uni, les Payment Services Regulations 2017 imposent de rembourser un paiement non autorisé au plus tard à la fin du jour ouvrable suivant, sauf soupçon raisonnable de fraude, et l’article 75 du Consumer Credit Act 1974 rend l’émetteur de la carte solidairement responsable avec le vendeur pour les achats unitaires de plus de 100 livres et jusqu’à 30 000 livres. Depuis le 7 octobre 2024, même les victimes d’escroqueries à virement autorisé, qui ont envoyé elles-mêmes l’argent à un fraudeur par Faster Payments ou CHAPS, peuvent être remboursées jusqu’à 85 000 livres : le Payment Systems Regulator a fixé cette limite pour Faster Payments, et la Banque d’Angleterre, qui exploite CHAPS, a retenu la même.
Rien de tel n’existe sur une blockchain publique. Une plateforme d’échange peut rembourser un client de sa poche, et un destinataire peut choisir de renvoyer les pièces, mais le protocole n’a pas de bouton de contestation. La FTC le formule ainsi : « you can usually only get your money back if the person you paid sends it back », c’est-à-dire que l’on ne récupère en général son argent que si la personne payée le renvoie. Notre guide pour éviter les arnaques crypto couvre les réflexes qui comptent le plus quand il n’y a pas de rétrofacturation.
Ce qu’il faut retenir, en tant qu’utilisateur ou commerçant
Un registre public et ordonné permet à des inconnus de s’accorder sur le paiement arrivé en premier sans passer par une banque. Il ne protège ni un paiement qui n’y figure pas encore, ni un paiement posé sur une chaîne bon marché à réécrire, et quelques habitudes en découlent.
- Un paiement non confirmé peut encore être remplacé ou écarté : traitez-le comme une promesse en attente.
- Adaptez l’attente au montant : plus la somme est grosse, plus il faut de confirmations avant de livrer ou de libérer des fonds.
- Une petite chaîne à preuve de travail demande bien plus de confirmations que Bitcoin, parce que son hashrate se loue à moindre coût.
- Un paiement crypto confirmé vers un escroc ne se rétrofacture pas : vérifiez l’adresse et le destinataire avant d’envoyer.
- Sur Ethereum, une transaction en attente peut être remplacée par une autre de même nonce ; sur Bitcoin, toute transaction non confirmée peut l’être avec des frais plus élevés.
La prochaine leçon de ce parcours porte sur la finalité et les réorganisations : jusqu’où une réorganisation peut descendre selon les chaînes, et à quel moment on peut parler d’un paiement final plutôt que simplement très probablement durable.
