Blockchain : comment empêcher la double dépense ?

La double dépense — dépenser la même unité numérique deux fois — est le défi historique de la monnaie électronique. Bitcoin (première cryptomonnaie lancée en 2009) l’a résolu en combinant une blockchain (registre distribué immuable), une fonction de hachage Secure Hash Algorithm 256 bits (SHA‑256) et un consensus Proof of Work (PoW, preuve de travail) assuré par le minage. Cet article explique, sous le capot, comment blocs, difficulté, hashrate et confirmations rendent la fraude impraticable, puis détaille les bonnes pratiques à adopter en situation réelle.

Résumé pour les pressés

Double dépense empêchée par la blockchain, le Proof of Work (PoW) et les confirmations
Rôle de SHA‑256, des entêtes de blocs, du nonce et de l’arbre de Merkle
Bonnes pratiques marchands: attendre N confirmations, gérer RBF, utiliser des nœuds

Double dépense : définition simple et risques concrets

Une double dépense survient lorsqu’un même détenteur tente d’utiliser la même pièce numérique dans deux transactions distinctes. Contrairement à un billet de 10 € (objet unique et physique), un fichier peut être copié. La solution n’est donc pas de “protéger un fichier”, mais d’empêcher que deux transactions conflictuelles soient toutes deux acceptées comme définitives. Bitcoin y parvient par un registre partagé tenu par des nœuds (ordinateurs participants) qui appliquent des règles de validation uniformes et un mécanisme de consensus qui rend extrêmement coûteuse toute réécriture de l’historique.

La blockchain en pratique : blocs, entêtes, Merkle et immutabilité

Une blockchain est une suite de blocs contenant des transactions validées. Chaque bloc possède :

un entête avec le hash (empreinte cryptographique) du bloc précédent, le hash de l’arbre de Merkle (Merkle root) des transactions, un horodatage, le niveau de difficulté et un nonce (nombre ajusté par les mineurs) ;
un ensemble de transactions, dont une transaction de coinbase (récompense du mineur).

Le chaînage des hashes fait la force du système : modifier une transaction changerait le Merkle root, donc le hash du bloc, donc celui de tous les blocs suivants. Cette « avalanche » cryptographique rend la falsification détectable et, grâce au PoW, économiquement prohibitive.

SHA‑256 : l’empreinte qui verrouille les données

Secure Hash Algorithm 256 bits (SHA‑256) transforme des données de taille quelconque en une empreinte de 256 bits :

déterministe (mêmes données → même hash),
à sens unique (on ne reconstitue pas l’entrée depuis le hash),
résistante aux collisions (trouver deux entrées différentes produisant le même hash est impraticable),
sensible à l’effet d’avalanche (un bit qui change → un hash totalement différent).

Dans Bitcoin, SHA‑256 est utilisé en double application dite double‑SHA‑256 pour sécuriser les entêtes de blocs et les identifiants de transaction. Cette propriété rend toute altération immédiatement détectable par n’importe quel nœud.

Proof of Work (PoW) et minage : pourquoi « réécrire » coûte cher

Le Proof of Work (PoW) exige qu’un mineur trouve, par essais successifs, un nonce qui fait que le hash de l’entête du bloc soit inférieur à une « cible » (target) fixée par la difficulté. Plus la difficulté est élevée, plus il faut d’essais (hashes) en moyenne. Ce « travail » consomme de l’électricité et du matériel (ASIC, Application‑Specific Integrated Circuit), ce qui donne une valeur économique aux blocs minés et un coût réel à toute tentative de fraude.

Difficulté et ajustement: Bitcoin ajuste la difficulté environ toutes les 2 016 blocs (≈ deux semaines) pour viser un temps moyen de 10 minutes par bloc, malgré les variations de hashrate (puissance totale de calcul du réseau).
Finalité probabiliste: chaque bloc ajouté au‑dessus d’une transaction accroît la probabilité que cette transaction ne puisse plus être annulée. Au bout de 6 confirmations (≈ 60 minutes en moyenne), le coût pour réécrire l’historique devient astronomique pour la plupart des attaquants.

UTXO, validation et règle de la chaîne la plus « lourde »

Bitcoin fonctionne avec des Unspent Transaction Outputs (UTXO, sorties non dépensées). Chaque transaction « consomme » des UTXO existants et en crée de nouveaux. Les nœuds complets (full nodes) vérifient que :

les UTXO dépensés existent et ne l’ont pas été précédemment,
les signatures cryptographiques ECDSA (Elliptic Curve Digital Signature Algorithm) sont valides,
les règles de consensus (tailles, scripts, limites) sont respectées.

Si deux transactions dépensent le même UTXO, seule l’une finira dans la chaîne valide. La règle du protocole impose de suivre la chaîne ayant le plus de travail cumulé (la plus « lourde » en PoW). Une tentative de double dépense qui n’est pas incluse en premier devra « battre » la chaîne publique en refaisant du travail plus vite que tout le réseau — mission quasi impossible sans majorité de calcul.

Comment la propagation du réseau limite les doubles dépenses

Quand une transaction est émise, elle est propagée de nœud en nœud (mempool, file des transactions non confirmées). Les mineurs choisissent un ensemble de transactions prioritaires (selon les frais, la validité et les politiques de relais) pour construire un bloc. Des optimisations (compact blocks, relay par inv) accélèrent la propagation des blocs et réduisent la fenêtre pendant laquelle deux versions concurrentes pourraient se diffuser. Plus la propagation est rapide et le réseau distribué, plus il est difficile d’exécuter une double dépense par « course » (race attack).

Types de doubles dépenses et pourquoi elles échouent

Race attack (attaque de course) : l’attaquant envoie une transaction au commerçant et, en parallèle, une transaction conflictuelle au réseau avec des frais plus élevés. Solution: n’acceptez pas de paiements « zéro confirmation » pour des montants significatifs, utilisez un nœud complet et attendez des confirmations.
Finney attack (attaque de Finney) : un mineur malveillant prépare un bloc privé contenant une transaction conflictuelle, puis paie le commerçant, et publie son bloc immédiatement après. Solution: attendre une confirmation rend ce vecteur inefficace.
Vector76 / attaque hybride: mélange de blocs privés et de propagation ciblée. Solution: attendre plusieurs confirmations et surveiller les réorganisations (reorgs).
51 % attack (majorité de hashrate) : un acteur contrôle >50 % du hashrate, mine une chaîne privée et la publie pour « écraser » des transactions confirmées. Théoriquement possible, mais économiquement dissuasif sur les grandes chaînes ; plus la valeur et le hashrate sont élevés, plus le coût devient prohibitif.

Rôle des confirmations : pourquoi « 6 confirmations » est la norme

Chaque confirmation est un bloc ajouté au‑dessus de la transaction :

0 confirmation: transaction vue en mempool, réversible, vulnérable aux attaques de course et au Replace‑By‑Fee (RBF, remplacement par les frais).
1 confirmation: déjà coûteux à renverser pour un attaquant isolé, mais pas impossible.
2 à 3 confirmations: suffisant pour des montants modestes.
6 confirmations: seuil historique de sécurité forte pour des montants élevés. Au‑delà, la probabilité d’annulation devient négligeable, sauf 51 % attack.

Le bon nombre dépend du risque acceptable, du montant, du contexte (boutique physique vs vente à distance) et du profil de chaîne (hashrate, liquidité, attaques passées).

Replace‑By‑Fee (RBF) et Child‑Pays‑For‑Parent (CPFP) expliqués

Replace‑By‑Fee (RBF): mécanisme permettant de remplacer une transaction non confirmée par une nouvelle version identique mais avec des frais plus élevés. Il améliore la fluidité du mempool en période de congestion, mais impose aux marchands d’attendre au moins une confirmation avant de livrer des biens non réversibles.
Child‑Pays‑For‑Parent (CPFP): une transaction « enfant » avec des frais élevés incite un mineur à inclure la transaction « parent » à faibles frais. Utile pour débloquer des paiements coincés.

Bonnes pratiques: afficher dans votre caisse si une transaction est signalée « RBF » et ajuster votre politique d’acceptation en conséquence.

SegWit, scripts et signatures : réduire les vecteurs d’erreurs

Segregated Witness (SegWit, séparation des signatures) a corrigé la malléabilité des transactions (capacité à modifier un identifiant de transaction sans changer son contenu économique). En supprimant cette fragilité, SegWit a renforcé la fiabilité des références aux transactions et la construction de couches supérieures (par exemple, Lightning). Des scripts standards (P2PKH, P2SH, P2WPKH, P2WSH) réduisent les risques d’erreurs et améliorent la compatibilité entre portefeuilles.

Ajustement de difficulté, hashrate et sécurité budgétaire

Hashrate: somme de la puissance de calcul sécurisant la chaîne. Plus il est élevé, plus il est cher de tenter une réorganisation profonde.
Ajustement de difficulté: toutes les 2 016 blocs, le protocole cible 10 minutes par bloc, amortissant les chocs (arrivée ou départ de mineurs).
Budget de sécurité: rémunération des mineurs via récompense de bloc (subvention qui diminue à chaque halving, division par deux environ tous les 210 000 blocs) et frais de transaction. À long terme, la sécurité dépendra davantage des frais, d’où l’importance d’un marché de frais sain.

SPV, nœuds complets et portefeuilles légers : qui vérifie quoi

Nœud complet (full node): télécharge et valide l’intégralité des blocs et des règles de consensus. C’est la référence pour savoir si une transaction est réellement confirmée.
Simplified Payment Verification (SPV, vérification simplifiée): un portefeuille léger vérifie que sa transaction est incluse dans une chaîne ayant du travail suffisant à l’aide d’entêtes et de preuves Merkle, sans valider tout le contenu. C’est fiable pour l’usage courant, mais moins robuste que l’exécution d’un nœud complet.
Bonnes pratiques marchands: interroger votre propre nœud complet pour éviter les dépendances à des tiers qui pourraient filtrer, censurer ou mal relayer des transactions.

Que se passe‑t‑il lors d’un fork ou d’un bloc orphelin ?

Un fork temporaire apparaît lorsque deux mineurs trouvent un bloc presque simultanément. Le réseau suit la branche qui devient la plus longue (ou la plus lourde en travail). L’autre bloc devient « orphelin » (orphaned block) et ses transactions retournent en mempool — elles seront généralement ré‑inclues rapidement. Pour un marchand, cela signifie qu’une seule confirmation peut occasionnellement être « réorganisée » ; après quelques confirmations, ce risque chute drastiquement.

Étapes d’une tentative de double dépense contrecarrée

L’attaquant émet deux transactions conflictuelles dépensant la même UTXO. Seule l’une est relayée largement.
Les mineurs incluent la transaction la plus vite propagée et/ou avec les frais les plus élevés.
La transaction concurrente est rejetée à l’inclusion car elle tenterait de dépenser un UTXO déjà consommé.
Après N confirmations, renverser l’historique nécessite de battre le PoW cumulé du réseau — économiquement irréaliste.

Guide pratique pour marchands et développeurs

Politique de confirmations: définissez des seuils par panier (ex: 1 confirmation < 200 €, 3 confirmations < 5 000 €, 6 confirmations au‑delà). Adaptez selon le risque et la chaîne.
Détection RBF: si la transaction est marquée RBF, attendez au moins 1 confirmation avant la livraison, même pour de petits montants.
Nœud complet: exécutez votre propre nœud (ou un cluster) et connectez votre caisse directement via un client RPC (Remote Procedure Call, appel de procédure distante) pour éviter un point de défaillance tiers.
Sécurité réseau: redondez vos pairs, surveillez les réorganisations et configurez des alertes en cas de mempool anormal ou de reorg > 1 bloc.
UX en boutique: pour les petits montants et si vous acceptez le risque 0‑conf, imposez des politiques d’atténuation (KYC léger local, caméras, seuils d’alerte, refus des transactions RBF, frais minimums).
Portefeuilles: privilégiez les wallets compatibles SegWit, affichant RBF/CPFP et les statuts de propagation. Documentez pour vos équipes les signaux à vérifier.
Comptabilité: enregistrez le moment de la première confirmation comme date de reconnaissance du paiement pour éviter des écritures à annuler en cas de reorg rare à 1 bloc.

Pourquoi la double dépense reste théorique sur Bitcoin

Sur Bitcoin, la combinaison hashrate élevé + difficulté ajustée + propagation rapide + normes de frais rend la double dépense pratiquement inapplicable au‑delà de quelques confirmations. Les attaques deviennent soit des fraudes d’opportunité sur des transactions non confirmées, soit des scénarios coûteux nécessitant une majorité de calcul. Dans les deux cas, des procédures simples — attendre N confirmations, vérifier RBF, utiliser un nœud — désamorcent le risque.

Questions fréquentes (FAQ)

La double dépense peut‑elle arriver si j’attends 6 confirmations ?

Le risque devient négligeable. Un attaquant devrait obtenir une puissance de calcul colossale et supporter un coût exorbitant pour réécrire l’historique au‑delà de 6 blocs.

Le Replace‑By‑Fee (RBF) rend‑il Bitcoin moins sûr ?

Non. RBF optimise la confirmation des transactions en période de congestion. Il impose en revanche d’attendre une confirmation avant de livrer des biens non réversibles.

Un wallet SPV est‑il suffisant pour accepter des paiements ?

Pour de petits montants, oui si vous suivez une politique prudente de confirmations. Pour un point de vente exigeant, préférez interroger votre propre nœud complet.

Les mineurs en pool peuvent‑ils orchestrer une double dépense ?

Théoriquement, avec une majorité de hashrate. En pratique, la coordination, le coût économique et le risque de réputation rendent ce scénario très improbable sur Bitcoin.

Pourquoi dit‑on « finalité probabiliste » sur Bitcoin ?

Parce que chaque confirmation augmente la probabilité que la transaction soit irréversible. Passé un certain nombre de confirmations, la probabilité d’annulation devient pratiquement nulle.

Conclusion : un équilibre entre cryptographie, économie et procédure

La blockchain empêche la double dépense grâce à une architecture où la cryptographie (SHA‑256, Merkle, signatures), l’économie (coût du PoW, incitations des mineurs) et la procédure (règles de validation, confirmations) s’alignent. Le résultat est un registre public qui rend toute réécriture coûteuse et détectable. Pour les professionnels, la sécurité se joue autant dans les paramètres techniques (SegWit, RBF/CPFP, nœud complet) que dans les process métier (seuils de confirmations, politiques de risque). En appliquant ces bonnes pratiques, vous profitez de paiements numériques globaux tout en conservant une surface de fraude minimale.