Double dépense

Supposons que Thomas possède une sortie reçue auparavant de 100 000 sat, les plus petites unités du bitcoin. Une sortie encore non dépensée s’appelle un UTXO. Il prépare un paiement de 99 000 sat à Alice, avec 1 000 sat de frais. Mais il pourrait aussi signer une autre transaction qui dépense le même UTXO et envoie les fonds ailleurs. Les deux utilisent la même source de fonds : elles sont donc en conflit. Ce n’est pas comme copier un fichier. Un nœud Bitcoin, l’ordinateur qui vérifie les règles, n’autorise pas deux dépenses de la même sortie dans une chaîne valide. La fraude réussirait si Alice livrait le bien pour le premier paiement, alors que l’historique accepté retenait finalement le second. Aucune monnaie supplémentaire n’a été créée ; Alice s’est fiée à la version perdante. Techniquement, chaque entrée désigne une sortie antérieure par l’identifiant de sa transaction, txid, et son numéro de sortie. Cette paire s’appelle un outpoint. [1] [3] [7]

Alice peut voir un paiement arriver en quelques secondes. Cela ne signifie pas qu’il est déjà inscrit dans un bloc. Le Mempool est la réserve locale des transactions non confirmées d’un nœud. Il n’existe ni Mempool mondial ni ordre d’arrivée commun à tout Bitcoin. Un autre nœud peut avoir reçu la version conflictuelle en premier ou ne pas encore avoir vu celle d’Alice. Une politique first-seen privilégie la première version reçue lors de la retransmission. Elle ne promet pas qu’un mineur l’inclura dans un bloc. Ni une capture du portefeuille ni un txid ne suffisent donc à prouver le règlement. Ce qui compte, c’est l’état du paiement précis dans une chaîne vérifiée de manière fiable. [2] [5]

Alice peut aussi être l’expéditrice d’un paiement honnête qui attend depuis longtemps. Replace-by-Fee (RBF) permet de remplacer une transaction non confirmée, généralement par une autre offrant davantage de frais. Le destinataire peut recevoir la même somme malgré le changement de txid. Le remplacement utilise au moins une partie des mêmes fonds : il est techniquement en conflit avec l’original sans que personne cherche à tromper le destinataire. Le contenu du nouveau paiement et les circonstances comptent, pas la seule mention RBF. Ce mécanisme peut toutefois aussi détourner les fonds vers une autre destination. Full-RBF est la politique par défaut de Bitcoin Core depuis la version 28 ; la transaction initiale n’a pas besoin de signaler qu’elle est remplaçable. Le remplacement reste soumis aux règles de frais et de protection contre les abus du nœud. L’absence de signal RBF ne rend donc pas un paiement non confirmé irréversible. [5] [6] [15]

Un paiement reçoit une confirmation lorsqu’il entre dans un bloc valide accepté par le nœud. Les blocs suivants rendent généralement cet historique plus difficile à remplacer et réduisent le risque de fraude. Aucun nombre n’offre toutefois la même sécurité dans toutes les situations. Perdre le prix d’un café n’a pas les mêmes conséquences que livrer une voiture ou autoriser un gros retrait d’une plateforme. Les six confirmations souvent citées sont une habitude, pas une règle de Bitcoin. Le destinataire doit tenir compte du montant, des recours possibles, des anomalies de la chaîne et de la qualité de ses informations. Isoler un nœud par une attaque de type Eclipse Attack peut fausser sa vision du réseau. L’attente accompagne donc la vérification ; elle ne la remplace pas. [2] [10]

Le passage d’un nœud à une autre branche valide s’appelle une réorganisation. Proof of Work atteste le travail nécessaire à la production des blocs ; le travail cumulé d’une branche s’appelle chainwork. Après confirmation, une transaction conflictuelle ne peut plus simplement évincer le paiement du Mempool. Une branche alternative valide doit omettre le paiement initial, inclure la seconde dépense et accumuler davantage de travail, appelé chainwork, que la chaîne active du destinataire. Une réorganisation de la chaîne peut aussi survenir sans fraude, par exemple lorsque des blocs sont minés presque simultanément ou lors d’une défaillance logicielle ou réseau. La double dépense contre la victime ne réussit que lorsque l’attaquant obtient une valeur grâce à la victoire de la transaction conflictuelle. Pour la transaction perdante du portefeuille, Bitcoin Core peut afficher un nombre négatif de confirmations dans le champ confirmations et les conflits associés dans walletconflicts. [4] [7] [8]

Le Hashrate mesure la vitesse de calcul du minage. Une part plus grande aide dans la compétition entre historiques, sans dispenser des autres règles. La probabilité qu’une branche minée en secret rattrape la chaîne honnête dépend notamment de la part de puissance de calcul détenue par l’attaquant et du nombre de confirmations. La valeur qu’il pourrait obtenir détermine surtout si l’attaque en vaut la peine. Une part inférieure à 50 % ne signifie pas une probabilité nulle ; une majorité durable augmente fortement les chances de rattraper l’autre branche. Même une majorité ne permet toutefois pas aux mineurs de falsifier des signatures, de dépenser les UTXO d’autrui, d’enfreindre les règles d’émission ou de forcer des nœuds complets à accepter un bloc invalide. Pour évaluer une attaque, il faut tenir compte de la puissance de calcul, de l’énergie et des récompenses auxquelles l’attaquant renonce en ne minant pas honnêtement. Le capital disponible, le risque d’échec et celui d’être découvert comptent aussi. Les gains peuvent aussi inclure ceux de positions sur les marchés financiers ; le seul prix de location des machines de minage ne suffit donc pas à établir une estimation. [1] [10] [12]

Race désigne ici une course de vitesse : le destinataire et les mineurs peuvent voir des transactions différentes en premier. Lors d’une attaque par course, ou race attack, le payeur envoie une transaction au commerçant et une transaction conflictuelle aux mineurs ou à d’autres nœuds. Il cherche à faire remettre les biens de manière irréversible avant qu’un bloc ne sélectionne l’une des versions. Le résultat dépend de la propagation des transactions, de la vue du réseau dont dispose le commerçant, du choix des mineurs et du moment de la remise. Davantage de nœuds indépendants observant le réseau améliorent la détection des conflits, mais ne garantissent pas un règlement irréversible. Les noms race, Finney et Vector76 désignent des scénarios d’attaque, et non des champs de données de transaction ou des règles de consensus différentes. [2] [11]

Finney attack désigne un scénario où l’attaquant dispose aussi d’une capacité de minage. Ce n’est pas une simple hausse des frais dans un portefeuille. Lors d’une attaque Finney, un attaquant capable de miner produit d’abord en secret un bloc contenant une transaction conflictuelle qui lui restitue la valeur. Il paie ensuite avec le même UTXO un commerçant qui accepte les paiements sans confirmation, puis publie le bloc caché après avoir reçu les biens. Le plan ne réussit que si le bloc reste utilisable et si le réseau l’accepte avant qu’un bloc concurrent honnête ne fasse échouer la préparation. L’attaquant risque donc la récompense du bloc et les coûts de minage. Attendre l’inclusion de la transaction du commerçant dans un bloc validé interrompt ce déroulement classique, sans supprimer le risque d’une réorganisation ultérieure de la chaîne. [1] [11]

RPC est l’interface de programmation du nœud. Les noms qui suivent sont des commandes et des champs destinés aux développeurs de systèmes de paiement, pas un autre type de confirmation. Le système du commerçant peut utiliser son propre nœud complet pour surveiller les dépenses conflictuelles dans le Mempool, appeler gettxspendingprevout, lire le champ walletconflicts, comparer le dernier bloc de la chaîne active et signaler la perte de confirmations. Davantage de nœuds connectés ou indépendants réduisent les angles morts, mais l’absence de conflit détecté constitue un faible indice de sécurité : l’attaquant peut garder la transaction conflictuelle secrète ou l’envoyer ailleurs. Un explorateur de blocs montre la vue de son propre nœud et peut avoir du retard. Détecter un conflit permet de suspendre la remise des biens. Cela ne peut toutefois ni imposer aux mineurs la transaction à choisir, ni rendre un paiement non confirmé équivalent à un paiement confirmé. [8] [9] [11]

Vérifiez le paiement réellement reçu, sa destination, son montant et ses confirmations. Un justificatif fourni par l’expéditeur ne remplace pas cette vérification. Votre propre nœud complet permet de contrôler directement les règles. Avec un service tiers, comprenez de qui dépendent vos informations et, éventuellement, la garde de vos fonds. Un système marchand doit relier la commande à des sorties précises et suivre aussi les remplacements. Un conflit ou la perte de confirmations doit suspendre une livraison irréversible. Un paiement ultérieur qui dépense de la monnaie rendue non confirmée dépend de la transaction initiale : il ne constitue pas une preuve indépendante de sa sécurité. Lightning Network permet des paiements rapides dans des canaux financés par une transaction Bitcoin. Les participants échangent des transactions commitment signées qui fixent la répartition des fonds. Lors d’une mise à jour, ils transmettent à l’autre partie des données secrètes permettant de les pénaliser s’ils publient ensuite un état périmé : cette invalidation de l’ancien état s’appelle revocation. La protection exige de détecter cette tentative et d’y réagir à temps. Le mécanisme diffère donc d’une livraison contre un transfert non confirmé sur la chaîne. Un canal ouvert sans confirmation, ou zero-conf channel, fait délibérément confiance à la partie qui le finance ; le risque de double dépense de ce financement subsiste. [13] [14]