Finality indique quand le règlement peut être considéré comme définitif. Pour Bitcoin, elle est probabiliste : un historique valide plus profond est plus difficile à remplacer, mais aucun nombre universel de confirmations ne garantit seul l’impossibilité d’une réorganisation ou l’exécution juridique du contrat.
Les blocs ajoutés au-dessus d’une transaction augmentent le travail requis pour remplacer son historique. La sécurité dépend aussi des ressources de l’attaquant et du réseau. Finality n’est donc pas un instant fixe où le protocole délivre un certificat mathématique d’irréversibilité. [Bitcoin Developer Guide — Block Chain][Bitcoin Developer Guide — Payment Processing]
Le nœud vérifie d’abord les règles puis choisit la chaîne valide ayant le plus de travail cumulé. Le nombre de blocs, de nœuds connectés ou les votes des détenteurs ne remplacent pas ce choix. Davantage de travail ne rend pas une transaction invalide valide. [Bitcoin Developer Guide — Block Chain]
Exemple construit : bloc de transaction à hauteur 800000, sommet de la même chaîne active à 800005. Cela donne 800005 − 800000 + 1 = 6 confirmations, bloc de transaction compris. Une présence dans le mempool seule vaut 0 confirmation, pas la première. [Bitcoin Developer Guide — Payment Processing][Bitcoin Core 28.0 — getblockheader]
Une réorganisation peut retirer un bloc de la branche active. Bitcoin Core 28.0 getblockheader indique alors confirmations = -1. Cela ne signifie pas perdre tous ses paiements : la transaction peut aussi figurer dans la nouvelle branche, rester non confirmée ou être conflictuelle ; revérifier son état. [Bitcoin Developer Guide — Block Chain][Bitcoin Core 28.0 — getblockheader]
Le guide de développement cite 6 confirmations comme seuil courant pour les paiements importants tout en prévoyant une analyse des risques. C’est une décision du destinataire, pas une modification du consensus. Une moyenne d’environ une heure ne garantit pas six blocs en une heure. [Bitcoin Developer Guide — Payment Processing]
PFMI exigent de définir clairement le moment du règlement définitif et la limite de révocabilité des instructions. Le nombre de confirmations ne détermine pas seul l’effet juridique d’un contrat, paiement bancaire ou transfert de propriété. L’acceptation technique de BTC ne remplit pas toutes les obligations commerciales. [BIS — PFMI principle 8]
Bitcoin ne possède pas de bouton ordinaire de prestataire pour révoquer un paiement confirmé. Un remboursement volontaire est une nouvelle transaction du destinataire et n’efface pas le transfert initial. Vérifier destinataire et montant avant l’envoi, pas seulement après le seuil choisi. [Bitcoin.org — Some things you need to know]
Consigner transaction, bloc et source de vérification ; surveiller l’actualité du nœud et les changements de branche active. confirmations est l’état à l’interrogation, pas un certificat permanent. Prévoir la réponse à une baisse ou un conflit pour ne pas traiter un ancien instantané comme une preuve nouvelle. [Bitcoin Developer Guide — Payment Processing][Bitcoin Core 28.0 — getblockheader]
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, Nakamoto consensus, Delivery versus payment.