La vie d’une transaction

Curiosité

1. Pourquoi un nœud doit-il vérifier une transaction avant même de savoir si elle sera minée ?
2. Qu’est-ce qui rend un bloc plus « réel » qu’un autre lorsque deux blocs apparaissent simultanément ?
3. Pourquoi six confirmations sont-elles devenues une convention, et dans quels cas est-ce trop ou trop peu ?

Explorer

1. Le parcours commence dans le logiciel de portefeuille. L’utilisateur sélectionne des sorties de transaction non dépensées (UTXO) précises pour couvrir le paiement et les frais. Le portefeuille construit un nouvel objet transaction, en définissant des entrées qui font référence à des sorties précédentes par leur identifiant de transaction et leur index, ainsi que des sorties qui attribuent une valeur aux adresses des destinataires ou à des adresses de change. Chaque entrée est signée avec la clé privée correspondant à son script de verrouillage, ce qui produit des signatures numériques prouvant la propriété sans révéler la clé elle-même.
2. La transaction entièrement signée est sérialisée au format binaire et diffusée aux pairs connectés sur le réseau pair-à-pair. À sa réception, chaque nœud la valide de manière indépendante au regard des règles de consensus : il vérifie que les entrées couvrent les sorties, contrôle les signatures cryptographiques, s’assure qu’aucun UTXO existant n’est dépensé deux fois et valide la logique des scripts. Si la transaction est valide au regard de sa politique, le nœud l’ajoute à son mempool local et l’annonce à ses pairs par des messages « inv » (inventaire) ; les pairs qui ne l’ont pas demandent la transaction complète avec « getdata ».
3. Les mineurs surveillent en permanence leur mempool à la recherche de transactions rentables. Ils sélectionnent un ensemble de transactions à taux de frais élevé pour les inclure dans un modèle de bloc candidat, qui contient aussi la transaction coinbase attribuant la subvention de bloc en vigueur et les frais perçus. Le mineur effectue ensuite la preuve de travail, en hachant l’en-tête du bloc de façon répétée jusqu’à trouver un hash qui satisfait la cible de difficulté actuelle du réseau. Ce travail rend le bloc coûteux à produire et peu coûteux à vérifier ; une fois trouvé, le bloc est diffusé sur tout le réseau.
4. Les nœuds qui reçoivent le nouveau bloc vérifient sa preuve de travail et la validité de ses transactions avant de l’ajouter à leur copie locale de la chaîne. Les transactions de ce bloc sont désormais considérées comme confirmées à une profondeur de un. Leurs entrées sont marquées comme dépensées dans l’ensemble des UTXO, et leurs sorties deviennent dépensables une fois écoulés les éventuels verrous temporels ou périodes de maturité requis. Si un bloc concurrent apparaît à la même hauteur, les nœuds suivent la branche qui cumule le plus de travail ; si une courte réorganisation remplace un bloc, ses transactions retournent dans le mempool, sauf si la nouvelle branche les inclut déjà.
5. La sécurité augmente avec chaque bloc ajouté au-dessus du bloc de confirmation. Les tableaux du livre blanc montrent qu’un attaquant disposant de 10 % de la puissance de hachage a moins de 0,1 % de chances de rattraper un retard de cinq blocs. Six confirmations, soit environ une heure, sont devenues une convention courante à partir de ce type d’analyse, même si le risque réel dépend de la part de l’attaquant et du montant en jeu. Si certains commerçants acceptent des paiements sans confirmation pour de petits montants, les transferts plus importants attendent généralement plusieurs confirmations afin de limiter le risque d’une attaque par double dépense via une réorganisation de la chaîne.
6. Les transactions coinbase, qui créent de nouveaux bitcoins à partir des récompenses de minage et des frais, sont soumises à une restriction particulière : leurs sorties ne peuvent pas être dépensées avant d’avoir atteint 100 confirmations. Cette règle existe parce qu’une sortie coinbase disparaît si son bloc est remplacé lors d’une réorganisation ; ce délai empêche ces pièces de se propager dans des transactions ultérieures qui deviendraient alors invalides. Pour les transferts ordinaires entre utilisateurs, ce délai n’existe pas ; une fois confirmées, les sorties sont techniquement dépensables, mais attendre davantage de confirmations relève d’une décision de gestion des risques, fondée sur la valeur en jeu et les hypothèses de confiance.

Faits clés

Exercice neuf, six, trois, un

Vérification des faits

Les dates, les chiffres et les affirmations ont été vérifiés à l’aide des sources publiées listées ci-dessous.

• S. Nakamoto, 'Bitcoin: A Peer-to-Peer Electronic Cash System', Section 11 (2008)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 10
• Bitcoin Developer Guide, 'P2P Network' documentation