Le nombre de validations est un état dérivé et non un champ stocké dans la transaction. Si une transaction se trouve dans un bloc de hauteur h et que la pointe de la chaîne active est H, sa profondeur est H − h + 1. Une transaction dans le pool de mémoire n'a aucun commit ; Bitcoin Core peut afficher une valeur négative pour une transaction de portefeuille conflictuelle, indiquant la profondeur du conflit.
L'envoi n'est pas une confirmation. Chaque nœud applique indépendamment la politique d'admission à son pool de mémoire, et différents nœuds peuvent voir un ensemble différent en raison du temps, des frais, des conflits, des limites ou des paramètres des packages. RBF peut remplacer une transaction non confirmée et le paiement vu par le commerçant peut disparaître sans entrer dans le bloc. Ainsi, le zéro conf échange la vitesse contre le risque de doubles dépenses et d’une vue incomplète du réseau ; Ni le txid ni la page de l'explorateur ne sont des colonies. [Guide du développeur Bitcoin — Transactions] [Bitcoin Core — Cohérence JSON-RPC] [BIP 125 — Opt-in Remplacement complet par frais]
Un mineur peut sélectionner une transaction dans un bloc candidat, mais la première confirmation n'a lieu que lorsque le nœud de validation accepte le bloc et que le bloc se trouve dans sa chaîne active avec le plus grand chaîne. Le nœud complet vérifie la preuve du travail, les scripts, l'existence et la non-dépense des intrants, les montants et autres règles de consensus ; un mineur ne peut pas racheter une dépense invalide simplement en l'inscrivant. La racine Merkle valide la transaction dans le bloc et une référence au bloc précédent la place dans la preuve de l'historique de travail. [Bitcoin Core — Validation] [Bitcoin Core — validation.cpp]
Si le bloc de transaction est à la hauteur h et que la pointe actuelle du nœud est H, le décompte est H − h + 1 : le bloc lui-même est compté en premier. La valeur est générée par rapport au bloc le mieux vérifié de ce nœud, de sorte que la pointe peut varier légèrement entre les nœuds. Il n’est pas écrit dans une transaction, n’augmente pas avec le temps et ne peut pas être déterminé de manière fiable à partir d’un horodatage. Bitcoin Core renvoie le blockhash, la hauteur du bloc et les confirmations comme état du portefeuille ou vue UTXO. [Guide du développeur Bitcoin – Chaîne de blocs] [Bitcoin Core RPC – gettransaction] [Bitcoin Core RPC – getbestblockhash]
Si une branche valide concurrente obtient plus de chaîne, le nœud détachera les blocs de l'ancienne pointe et attachera la branche gagnante. Une transaction d'un bloc détaché peut revenir au mempool si elle reste valide, validée à une hauteur différente ou entrer en conflit parce qu'une nouvelle branche a dépensé la même entrée. Les confirmations négatives dans Bitcoin Core sont une convention de portefeuille pour la profondeur du conflit, et non des blocages négatifs dans le consensus. [Bitcoin Core RPC - gettransaction] [Bitcoin Core - validation.cpp]
Des confirmations supplémentaires ajoutent une preuve de travail pour une transaction, ce qui la rend généralement plus coûteuse et peu susceptible de réécrire l'historique. Ils ne créent pas de finalité déterministe. Le calcul de rattrapage du livre blanc et les modèles ultérieurs dépendent de la part de hashrate de l'attaquant, du comportement du réseau honnête et des observations du récepteur. Les « Six Confirmations » sont un dispositif historique, et non une constante de consensus ou une limite de sécurité universelle ; une réorganisation en profondeur est encore possible en principe. [Livre blanc Bitcoin — Preuve de travail et calculs] [Rosenfeld — Analyse des doubles dépenses basées sur le hashrate]
Le décompte est requis par le destinataire, l'échange ou le protocole en aval, et non par la transaction elle-même. Le café, l'émission non remboursable de produits coûteux, le dépôt en bourse et l'ouverture des canaux présentent des taux de perte et d'attente différents. La politique doit prendre en compte la valeur, la réversibilité des performances, la motivation et le hashrate de l'attaquant, les conflits ou RBF, la garde et le backend, le risque d'éclipse et l'état inhabituel de la chaîne. La confirmation atténue le risque d'écrasement de la chaîne ; ne réparera pas une clé volée, une mauvaise adresse ou une fraude de la contrepartie. [BIP 125 — Opt-in Remplacement complet par frais] [Rosenfeld — Analyse des doubles dépenses basées sur le hashrate]
Bitcoin vise en moyenne une dizaine de minutes entre les blocs, mais les arrivées de preuves de travail sont aléatoires : le bloc suivant peut arriver en quelques secondes ou heures. Des frais plus élevés peuvent améliorer l'ordre de sélection des mineurs et l'économie des packages RBF ou CPFP, mais aucun frais n'achète un temps fixe et n'accélère pas la création de blocs. Une transaction bon marché peut attendre plusieurs blocs ou être supprimée du pool de mémoire ; une estimation est une probabilité, pas une date limite. [Guide du développeur Bitcoin – Chaîne de blocs] [Guide du développeur Bitcoin – Transactions]
Le nœud complet valide la chaîne et répond selon sa propre pointe active. Le client SPV vérifie la preuve de travail dans les en-têtes et l'inclusion de la preuve Merkle, mais n'exécute pas lui-même toutes les règles de consensus ; le service de garde ajoute également sa propre politique de crédit et de risque. Même le résultat RPC d'un nœud complet est un instantané qui peut être modifié par réorganisation. La question n’est donc pas seulement « combien de confirmations », mais aussi à quelle vision de la chaîne, validation et conservation l’utilisateur fait confiance. [Livre blanc Bitcoin — Preuve de travail et calculs] [Bitcoin Core — Validation] [Bitcoin Core — Cohérence JSON-RPC]
D'autres cours commencent également par une confirmation. La sortie de Coinbase est soumise à COINBASE_MATURITY = 100 et ne peut être dépensée qu'après 100 nouveaux blocs ; il s'agit d'une règle différente de la politique de paiement habituelle. Les timelocks relatifs BIP68, appliqués par le script BIP112 CHECKSEQUENCEVERIFY (CSV), mesurent l'âge du bloc de validation de sortie. Un parent non confirmé maintient les descendants à charge ; pour qu'un enfant soit affirmé, ses ancêtres doivent être dans le même bloc ou dans un bloc plus ancien. [Bitcoin Core – consensus.h] [BIP 112 – CHECKSEQUENCEVERIFY]
BOLT 2 permet à un récepteur de canal Lightning de choisir les transactions de financement minimum_profondeur avant Channel_ready ; le nombre valorise le financement des risques à double dépense. Un canal sans conf. définit minimum_profondeur à zéro et s'appuie consciemment sur la confiance du fonds et les contraintes de protocole plutôt que sur la finalité immédiate. Le financement de Coinbase est en attente d’immatriculation. L'opérateur doit surveiller le point de financement, la profondeur de la chaîne active et les réorganisations, et ne pas considérer le txid envoyé comme un canal ouvert. [BOLT 2 – Peer Protocol] [Bitcoin Optech – Canaux zéro conf]
Pour une vision complète, lisez aussi Bloc, Transaction, Reorg, Double dépense, Proof of Work, Bitcoin. Cette entrée est également citée par Double dépense, Transaction coinbase, Reorg, Stale Block.