La Finality désigne le caractère définitif du règlement : dans quelle mesure peut-on compter sur le maintien d’un transfert achevé ? Bitcoin apporte une assurance probabiliste, renforcée par le travail valide ajouté ensuite. Aucun seuil universel de confirmations n’exclut à lui seul un changement de branche ni ne détermine l’exécution juridique de l’ensemble d’un accord.
Paul constate d’abord que son portefeuille a connaissance de la transaction. Cela ne signifie pas encore qu’elle figure dans un bloc. Une fois ce bloc créé, les blocs suivants augmentent le travail qu’il faudrait dépasser pour remplacer cet historique. C’est ainsi que la Finality se renforce en pratique. Les moyens d’un éventuel attaquant et l’état du réseau comptent aussi. Le protocole ne délivre pas de certificat mathématique d’irréversibilité : le destinataire apprécie la solidité des éléments dont il dispose pour accepter un paiement donné. [1] [2]
Un Full Node vérifie lui-même les règles de Bitcoin. Il n’accepte pas un historique simplement parce qu’il est long. Il en contrôle d’abord la validité, puis choisit, parmi les branches valides, celle qui cumule le plus de travail. Il s’agit du travail attesté par les blocs, et non d’un vote compté en personnes ou en bitcoins détenus. Davantage de travail ne rend pas valide une transaction invalide. Paul doit donc vérifier à la fois le respect des règles et la profondeur de son paiement dans l’historique valide actuellement suivi. [1]
Dans notre exemple, la transaction de Paul se trouve dans le bloc de hauteur 800000, et le dernier bloc de cette même branche est à la hauteur 800005. La hauteur indique une position, pas une heure. Le calcul donne 800005 − 800000 + 1 = 6 confirmations : le bloc contenant la transaction est lui-même inclus. On ne compte donc pas seulement les blocs arrivés après lui. Un paiement présent uniquement dans le mempool, l’ensemble des transactions non confirmées de ce nœud, a 0 confirmation. Attendre ne suffit pas à faire monter ce nombre. [2] [3]
Le réseau peut brièvement connaître des blocs concurrents, puis poursuivre sur une autre branche valide cumulant davantage de travail. Ce changement d’historique actif s’appelle une réorganisation. Dans la documentation de Bitcoin Core 28.0, la requête d’en-tête getblockheader renvoie confirmations = -1 si le bloc n’appartient pas à la chaîne active. Cette indication concerne le bloc ; elle ne signifie pas que tous ses paiements sont perdus. La transaction de Paul peut également figurer dans la nouvelle branche, attendre sans confirmation ou entrer en conflit avec une autre. Il faut vérifier à nouveau son état précis. [1] [3]
Le guide des développeurs cite 6 confirmations comme seuil courant pour les paiements importants, tout en expliquant la nécessité d’évaluer le risque. C’est une règle d’acceptation du destinataire, pas un changement du consensus Bitcoin. Paul doit considérer la valeur du vélo, la perte possible et la fiabilité de sa vérification ; le chiffre ne décide pas pour lui. Une moyenne d’environ une heure ne signifie pas non plus que six blocs arrivent toujours en une heure. Le minage n’a pas d’horaire fixe, et une ancienne recommandation générale n’est pas une garantie universelle. [2]
Paul peut avoir reçu des BTC confirmés tout en restant en désaccord sur la remise ou l’état du vélo. Les PFMI, principes internationaux pour les infrastructures de marchés financiers, demandent un moment de règlement définitif clairement défini ainsi qu’une limite après laquelle un participant ne peut plus révoquer une instruction. Ce cadre diffère du comptage des blocs Bitcoin. Les confirmations ne déterminent pas seules les effets juridiques du contrat, le caractère définitif d’un paiement bancaire ou le transfert de propriété. Vérifier le paiement reste essentiel, sans remplacer les autres conditions de la vente. [4]
Si Paul et l’acheteur conviennent d’un remboursement, celui-ci passe normalement par une nouvelle transaction émise par le destinataire du paiement initial. Le premier transfert reste dans l’historique. Bitcoin n’a pas de service central capable d’annuler sur demande un paiement confirmé en appuyant sur un bouton. Une réorganisation modifie l’historique actif du réseau ; ce n’est pas un service après-vente pour corriger les erreurs. Il faut donc vérifier le destinataire et le montant avant l’envoi. Des confirmations supplémentaires ne corrigent pas un paiement mal saisi. [5]
Pour l’exploitant d’une application de paiement, l’acceptation ne marque pas la fin du travail. Il faut enregistrer la transaction, son bloc et la source de vérification, et repérer un nœud resté en retard sur le réseau. La valeur confirmations décrit la situation au moment de la requête, pas un certificat permanent. Si elle diminue ou qu’un conflit apparaît, l’application doit suivre des règles prévues à l’avance et vérifier de nouveau la branche active. Une ancienne capture d’écran n’est pas une preuve nouvelle. Paul doit décider à partir de l’état actuel du paiement, pas seulement de ce qu’affichait auparavant son portefeuille. [2] [3]
Pour une vision complète, lisez aussi Confirmation, Proof of Work, Settlement risk, Delivery versus payment. Cette entrée est également citée par Byzantine Generals Problem, Delivery versus payment.