Le conflit peut être observé avant même le règlement, mais une double dépense réussie ne se produit que lorsque la victime dépense de la valeur pour une transaction et que l'autre gagne dans la chaîne reçue. Par conséquent, un paiement de portefeuille remplacé, une augmentation involontaire des frais ou un conflit infructueux ne constituent pas automatiquement une fraude. La course au zéro conf et l’écrasement des blocs validés entraînent des coûts et des risques fondamentalement différents.
Chaque entrée fait référence à la sortie précédente en utilisant un txid et un index. Deux transactions sont en conflit lorsqu'au moins une entrée fait référence au même point de sortie non dépensé, mais elles ne peuvent pas payer en même temps. Lors de la validation d'un bloc, le nœud vérifie que l'entrée existe et n'a pas été dépensée plus tôt dans l'historique donné ou ailleurs dans le même bloc. Une seule branche survit dans un ensemble UTXO valide ; l'attaque ne produit pas de copie du satoshi, elle tente de faire agir le destinataire sur la branche qui perd. [Livre blanc Bitcoin — Transactions, serveur d'horodatage et calculs] [Guide du développeur Bitcoin — Transactions] [Bitcoin Core — validation.cpp]
Il n'y a pas de pool de mémoire global ni d'ordre consensuel des transactions non validées avant l'extraction. Les pairs peuvent d'abord voir divers conflits dus à la promotion, à la topologie, à la politique tarifaire, au statut du package ou à l'isolement de l'éclipse. Le premier vu est une politique de relais et non une obligation pour les mineurs de confirmer la première option. Un txid sur le backend du commerçant prouve uniquement qu'un candidat signé est arrivé, et non que l'ensemble du réseau l'a vu ou a gagné un bloc. [Guide du développeur Bitcoin – Traitement des paiements] [Bitcoin Core – Remplacements de Mempool]
Le remplacement par frais permet à un nœud de remplacer les conflits de pool de mémoire qui respectent les règles de frais et anti-DoS ; full-RBF est la politique par défaut dans Bitcoin Core depuis la version 28. L'expéditeur peut légitimement augmenter les frais de paiement bloqués et préserver le résultat du destinataire, ou rediriger la valeur. Dans les deux cas, le consensus voit des candidats communs et accepte la variante dans l’histoire minière valide. Un signal RBF, un remplacement ou une bosse ne prouve pas à lui seul une fraude ; une transaction sans signal n'est encore une fois pas sûre pour zero-conf. [Bitcoin Core – Remplacements de Mempool] [BIP 125 – Remplacement complet moyennant des frais]
Dans une attaque de course, le payeur envoie une transaction au commerçant et le conflit aux mineurs ou à d'autres pairs, de sorte que le commerçant émette des marchandises non retournables avant que le bloc ne sélectionne une option. Le résultat dépend de la promotion, de la vue réseau du commerçant, du choix des mineurs et du temps de transfert. Des auditeurs plus indépendants amélioreront la détection, mais ne créeront pas de finalité déterministe. Les noms Race, Finney et Vector76 sont des modèles de scénarios, et non des tableaux de transactions ou diverses règles de consensus. [Guide du développeur Bitcoin – Traitement des paiements] [Karam et al. — Mauvais comportement dans Bitcoin]
Un attaquant de type Finney, capable d'exploiter, trouve d'abord en privé le bloc contenant le conflit, lui renvoyant la valeur, puis paie le zéro-conf au commerçant avec le même UTXO et publie le bloc caché après avoir reçu la marchandise. Le plan ne réussit que si le bloc reste utilisable et est accepté par le réseau avant qu'un bloc rival honnête ne contrecarre la préparation ; l'attaquant risque à la fois la récompense de bloc et les coûts de minage. Attendre que la transaction du commerçant soit incluse dans le bloc vérifié met fin à la séquence classique, mais ne supprime pas le risque de réorganisation ultérieur. [Livre blanc Bitcoin — Transactions, serveur d'horodatage et calculs] [Karame et al. — Mauvais comportement dans Bitcoin]
Une fois confirmé, le conflit ne peut plus simplement pousser le paiement hors du pool de mémoire : la branche valide alternative doit ignorer le paiement, inclure la deuxième dépense et gagner plus de chaîne que la chaîne active du destinataire. Une réorganisation peut se produire même sans fraude dans des blocs quasi simultanés ou sans incident logiciel ou réseau ; une double dépense réussie contre la victime ne sert qu'à gagner de la valeur en gagnant le conflit. Bitcoin Core peut afficher des confirmations négatives et des conflits de portefeuille pour une transaction de portefeuille perdue. [Bitcoin Core — Validation] [Bitcoin Core — validation.cpp] [Bitcoin Core RPC — gettransaction]
La part de hashrate de l'attaquant, la profondeur de confirmation et la valeur pouvant être obtenue déterminent la course stochastique du travail privé et honnête. En dessous de 50 % ne signifie pas zéro chance ; La majorité permanente augmente considérablement la possibilité de rattraper son retard, mais elle ne permet pas aux mineurs de falsifier des signatures, de dépenser des UTXO étrangers, de dépasser les émissions ou de forcer des nœuds complets à accepter un bloc invalide. Les coûts comprennent la puissance de hachage, l'énergie, les récompenses honnêtes perdues, le risque de perte, la liquidité et l'exposition ; les revenus peuvent également inclure des positions sur le marché, de sorte que le simple prix de location des machines ne suffit pas. [Livre blanc Bitcoin — Transactions, serveur d'horodatage et calculs] [Rosenfeld — Analyse des doubles dépenses basées sur le hashrate] [Garay, Kiayias et Leonardos — Le protocole Bitcoin Backbone]
Chaque validation supplémentaire oblige la branche alternative à refaire une plus grande partie du retard et, compte tenu des hypothèses, réduit les chances de succès. Il n’existe pas de numéro de sécurité universel : le café, la voiture, le dépôt en bourse et le retrait non remboursable présentent des valeurs, des motivations et des possibilités de correction différentes. Les six affirmations souvent citées constituent une convention et non un consensus. La politique devrait également surveiller la distribution du hashrate, les réorganisations inhabituelles, la confiance dans le backend, le risque d'éclipse et la réversibilité des transferts. [Guide du développeur Bitcoin – Traitement des paiements] [Rosenfeld – Analyse des doubles dépenses basées sur le hashrate]
Le backend peut surveiller les dépenses conflictuelles du pool de mémoire sur son propre nœud complet, appeler gettxsendingprevout, lire les conflits de portefeuille, comparer les pourboires actifs et avertir de la perte de confirmation. Un plus grand nombre de pairs ou de nœuds indépendants réduisent les angles morts, mais l'absence de conflit détecté est une preuve faible : un attaquant peut l'intercepter ou l'envoyer ailleurs. L'Explorateur affiche une vue de nœud personnalisée et peut être retardé. La détection permet d'arrêter la distribution ; il ne peut pas dire aux mineurs de gagner ou transformer le zéro-conf en confirmation. [Bitcoin Core RPC — gettransaction] [Bitcoin Core RPC — gettxsendingprevout] [Karame et al. — Mauvais comportement dans Bitcoin]
Pour le règlement onchain, validez avec votre propre nœud complet, liez la commande avec le txid exact, les sorties et le montant, définissez la profondeur en fonction de la perte possible, en cas de réorganisation ou de conflit, arrêtez l'exécution et séparez le solde crédité du montant retirable. Ne traitez pas un descendant de modification non confirmé comme indépendant du parent. Lightning gère différemment les paiements récurrents rapides : un point de financement confirmé ancre le canal et les règles d'engagement/révocation contrôlent l'état hors chaîne ; Le canal zéro conf fait sciemment confiance au bailleur de fonds et n’élimine pas le risque de double dépense de financement. [BOLT 2 – Peer Protocol] [Bitcoin Optech – Canaux zéro conf]
Pour une vision complète, lisez aussi Transaction, Confirmation, Mempool, Proof of Work, Replace-by-Fee (RBF), Bitcoin. Cette entrée est également citée par Confirmation, Reorg, Stale Block, Replace-by-Fee (RBF).