Confirmation

Alice envoie à un ami 20 000 sat, les plus petites unités du bitcoin. Son portefeuille affiche Envoyé et son ami voit déjà le paiement entrant, mais avec zéro confirmation. Ce n’est pas contradictoire : l’information a circulé entre les nœuds, les ordinateurs qui vérifient Bitcoin, sans encore figurer dans un bloc. Le Mempool est la réserve locale de transactions non confirmées d’un nœud, pas une file unique pour tout le réseau. Quand le paiement entre dans un bloc accepté, il obtient sa première confirmation. Le bloc suivant apporte la deuxième, puis le suivant la troisième. Alice n’a rien à renvoyer. Diffuser une transaction ne la confirme pas, et son identifiant txid ne garantit pas non plus sa confirmation. Une transaction en attente peut être remplacée, notamment avec Replace-by-Fee (RBF) pour relever les frais. Accepter un paiement sans confirmation s’appelle zero-conf et implique le risque qu’une autre dépense des mêmes fonds soit finalement confirmée. [4] [8] [11]

Un mineur choisit des transactions pour un nouveau bloc et cherche un Proof of Work valide, le résultat des calculs coûteux exigés par les règles de Bitcoin. Les autres nœuds complets vérifient ensuite eux-mêmes le bloc : signatures, montants et conditions de dépense sont-ils corrects, et les fonds sont-ils encore disponibles ? Ce n’est ni un vote des mineurs ni le visa d’une entreprise. Inclure un paiement invalide dans un bloc ne le rend pas valide. Un nœud ne le considère comme confirmé que dans la chaîne qu’il accepte. Parmi les branches valides, il choisit celle ayant le plus de travail accumulé, appelé chainwork. Chaque bloc renvoie au précédent : modifier l’historique ancien oblige donc aussi à reconstruire ce qui le suit. [2] [7]

Bitcoin vise dix minutes en moyenne entre les blocs, pas un horaire fixe. Le prochain bloc peut arriver en quelques secondes ou bien plus tard. Une heure d’attente ne signifie donc pas automatiquement six confirmations. Un taux de frais supérieur peut favoriser le choix de votre transaction par un mineur, mais ne fait pas arriver les blocs plus vite. Certains portefeuilles proposent RBF, le remplacement d’une transaction en attente par une autre payant davantage, ou CPFP (Child Pays for Parent) : une transaction dépendante ajoute assez de frais pour rendre rentable son inclusion avec sa transaction parente. Cela dépend du portefeuille et de la transaction. Des frais faibles peuvent entraîner une longue attente ou un retrait du Mempool d’un nœud. Prenez l’estimation pour ce qu’elle est, pas pour un délai promis. [3] [4]

Le destinataire ou le service choisit combien de confirmations il exige avant d’accepter le paiement. Un petit achat peut justifier un risque différent de la remise irréversible d’un objet coûteux. Si une plateforme attend plusieurs confirmations, votre transaction peut déjà être dans la blockchain sans que votre compte y soit crédité. Ce n’est pas forcément une erreur. Vérifiez montant, destination et état dans votre portefeuille, ainsi que les conditions de crédit du service. La source d’information compte également. Un attaquant peut isoler un nœud et lui présenter une vue restreinte du réseau : c’est une Eclipse Attack. L’attente adaptée dépend donc de la valeur, des recours possibles, de la confiance dans l’autre partie et du mode de vérification. Le nombre de confirmations seul ne protège pas d’une clé volée. [11] [13]

Imaginez le paiement comme une inscription au-dessus de laquelle s’accumulent de nouvelles pages d’histoire. Modifier une page ancienne ne suffit pas : un attaquant devrait produire une suite concurrente valide avec assez de travail accumulé. Dans les conditions habituelles, les confirmations supplémentaires compliquent cette tâche. Mais le résultat dépend aussi de sa puissance de calcul et de l’état du réseau. Les six confirmations souvent citées sont un repère historique, pas une règle de consensus ni une frontière magique de sécurité totale. Un seul chiffre fixe ne peut honnêtement représenter la probabilité de réécriture dans toutes les situations. Davantage de confirmations ne corrigent pas non plus une mauvaise adresse ou un paiement à un escroc. [1] [13]

Une bifurcation brève peut survenir sans attaque lorsque deux mineurs trouvent un bloc presque simultanément. Le passage d’un nœud à une autre branche gagnante s’appelle une réorganisation. Une sortie inscrit un montant et ses conditions de dépense ; une entrée d’une transaction ultérieure la désigne et la dépense. Une sortie non dépensée est appelée UTXO. Si une branche concurrente valide accumule davantage de travail, ou chainwork, le nœud détache les derniers blocs de son ancienne chaîne et rattache la branche gagnante. Une transaction issue d’un bloc détaché peut revenir dans le Mempool si elle reste valide, ou être confirmée à une autre hauteur. Elle peut aussi devenir conflictuelle si la nouvelle branche dépense la même sortie que celle désignée par son entrée. Une valeur négative de confirmations dans Bitcoin Core est la manière dont le portefeuille exprime la profondeur du conflit. Elle ne signifie pas un nombre négatif de blocs dans les règles de consensus. [5] [7]

La hauteur d’un bloc est sa position dans la suite, comptée depuis le bloc initial numéroté zéro. Si le bloc de la transaction est à la hauteur h et que le dernier bloc de la chaîne active du nœud est à la hauteur H, le nombre de confirmations est H − h + 1. Le bloc contenant la transaction compte donc comme le premier. Le résultat dépend du meilleur bloc validé par ce nœud et peut ainsi différer brièvement entre nœuds à l’arrivée de nouveaux blocs. Il ne fait pas partie de la transaction, n’augmente pas par le seul écoulement du temps et ne peut pas être déduit de manière fiable d’un horodatage. Bitcoin Core renvoie des données comme blockhash, blockheight et confirmations selon l’état connu du portefeuille concerné ou de la vue des UTXO. [3] [5] [6]

SPV désigne la vérification simplifiée des paiements, tandis que RPC est une interface de programmation pour interroger un nœud. Les méthodes de vérification restent importantes même si deux applications affichent le même nombre. Un nœud complet valide la chaîne et répond selon l’extrémité actuelle de sa propre chaîne validée. Un client SPV vérifie Proof of Work dans les en-têtes de blocs et une preuve de Merkle de l’inclusion de la transaction, mais ne vérifie pas lui-même toutes les règles de consensus. Une preuve de Merkle utilise une courte série d’empreintes cryptographiques pour établir qu’une transaction figure dans un bloc, sans télécharger toutes les transactions de ce bloc. Un service qui détient les fonds pour ses utilisateurs applique aussi ses propres règles de crédit des paiements et de gestion du risque. Même le résultat d’un appel RPC à un nœud complet décrit l’état à un instant donné, qu’une réorganisation peut modifier. Au-delà du nombre de confirmations, il faut donc savoir à qui l’utilisateur fait confiance pour la vue de la chaîne, la vérification et la garde des fonds. [1] [2] [8]

Une Coinbase Transaction est la première transaction particulière d’un bloc qui verse la récompense au mineur ; elle n’a aucun lien avec la plateforme Coinbase. Un verrou temporel limite le moment où les fonds peuvent être dépensés. BIP désigne une proposition technique ou un standard. La confirmation déclenche aussi certains délais du protocole. Une sortie de transaction coinbase est soumise à COINBASE_MATURITY = 100 : elle peut être dépensée au plus tôt dans un bloc dont la hauteur dépasse de 100 celle du bloc contenant cette transaction coinbase. Il s’agit d’un délai obligatoire avant de dépenser la récompense d’un bloc, et non d’un choix du destinataire d’un paiement ordinaire. Les verrous temporels relatifs de BIP68 se fondent sur la confirmation de la sortie dépensée et évaluent son âge selon des règles basées sur les blocs ou sur le temps. Un script est un court programme qui définit les conditions permettant de dépenser une sortie. L’instruction CHECKSEQUENCEVERIFY (CSV) de BIP112 permet d’imposer cette condition relative dans un script. Une transaction qui dépense une sortie non confirmée dépend toujours de celle qui l’a créée. Pour que la transaction suivante puisse être confirmée, ses ancêtres doivent figurer dans le même bloc ou dans un bloc antérieur. [9] [10]

Lightning Network permet des paiements par des canaux financés par des transactions Bitcoin. BOLT désigne ses spécifications techniques ; il s’agit ici d’ouvrir un canal, pas d’attendre un bloc pour chaque paiement dans celui-ci. BOLT 2 permet à la partie qui accepte un canal Lightning de préciser dans minimum_depth le nombre de confirmations requis pour la transaction de financement avant l’envoi de channel_ready. Cette exigence tient compte du risque de double dépense du financement. Un canal ouvert sans confirmation, ou zero-conf channel, fixe minimum_depth à zéro et repose délibérément sur la confiance envers le financeur et sur les restrictions du protocole. Il n’obtient pas pour autant un règlement immédiatement irréversible. Si la transaction de financement est elle-même une transaction coinbase, BOLT 2 impose à la partie qui n’ouvre pas le canal d’attendre au moins 100 blocs. L’opérateur doit suivre la sortie précise qui finance le canal, le funding outpoint, sa profondeur dans la chaîne active et les réorganisations. Un txid diffusé ne signifie pas à lui seul que le canal est ouvert. [12] [14]