Un nœud Bitcoin est un programme qui vérifie les blocs et les transactions. Un Reorg est le passage d’un nœud Bitcoin à une autre branche valide présentant davantage de Proof of Work cumulé, c’est-à-dire de travail attesté par le minage. Le nœud réévalue les derniers blocs et leurs paiements. Il ne modifie pas les règles de Bitcoin et ne donne à personne un bouton pour annuler les paiements d’autrui.
Anna reçoit 20 000 satoshis, les petites unités du bitcoin. Son portefeuille affiche une confirmation : le paiement figure dans un bloc accepté par son nœud. Celui-ci découvre ensuite une branche concurrente valide qui ne contient pas encore ce paiement. Dès que cette branche représente davantage de travail de minage cumulé, le nœud l’adopte. Ce remplacement d’une partie de l’historique s’appelle un Reorg. Le paiement d’Anna peut attendre de nouveau une confirmation sans que personne ait volé ses clés ou modifié sa signature. Ce n’est ni un vote ni le simple nombre de blocs qui décide, mais le chainwork : la somme du travail que chaque bloc atteste selon sa difficulté. Un nœud refuse une branche invalide même si elle représente plus de travail. [1] [4]
La suite dépend de la nouvelle branche. Si elle contient aussi le paiement d’Anna, il reste confirmé, même si son nombre de confirmations peut changer. Sinon, Bitcoin Core peut tenter de le remettre dans le Mempool, sa liste temporaire de transactions non confirmées en attente d’un bloc. Ce retour n’est pas garanti. Une sortie de transaction antérieure enregistre un montant et les conditions permettant de le dépenser. La nouvelle branche peut déjà avoir dépensé les mêmes fonds dans une autre transaction ; une sortie antérieure à dépenser peut aussi manquer, ou certaines conditions de délai ou d’admission ne plus être remplies. Un paiement qui attend de nouveau est donc différent d’un paiement que le nouvel historique ne permet plus. [1]
Une confirmation correspond au bloc contenant le paiement. Chaque bloc suivant ajoute une confirmation et du travail qu’une branche concurrente devrait dépasser. Un paiement dans le dernier bloc a donc une confirmation ; plus il est enfoui dans l’historique accepté, plus son remplacement devient généralement difficile. Mais aucun nombre fini de confirmations ne garantit mathématiquement qu’un remplacement est impossible. Commerçants et plateformes d’échange adaptent donc l’attente à la valeur du paiement et au risque qu’ils acceptent. [3] [5]
Un Reorg ne prouve pas à lui seul une attaque. Deux mineurs peuvent trouver presque simultanément des blocs ayant le même prédécesseur. L’information ne traverse pas le réseau instantanément : des nœuds suivent alors brièvement des extrémités différentes. Lorsqu’une branche valide accumule davantage de travail, ils l’adoptent ; le bloc abandonné est un Stale Block. Le même mécanisme peut toutefois servir à une attaque Double Spend : l’attaquant cherche à faire accepter un historique dans lequel les mêmes fonds ont été payés ailleurs. Il faut donc comprendre pourquoi le changement a eu lieu et quels paiements il a modifiés. [4] [5]
Lors d’un Reorg, le nœud garde les mêmes règles et choisit entre des historiques qui les respectent. Un Hard Fork modifie les règles de validité : l’ancien et le nouveau logiciel peuvent alors juger différemment le même bloc. Une réorganisation ne crée donc pas à elle seule une autre monnaie et ne réécrit pas les règles de Bitcoin. Les chapitres suivants expliquent comment le nœud effectue ce changement d’historique. [4]
Le tip désigne le dernier bloc de la branche actuellement acceptée. Le point de divergence est le dernier bloc commun à la chaîne actuellement active et à la branche alternative. La profondeur d’une réorganisation se décrit généralement par le nombre de blocs à l’extrémité de la chaîne active qu’il faut déconnecter pour revenir à cet ancêtre commun. Une réorganisation d’un bloc remplace la pointe ; une réorganisation plus profonde annule plusieurs blocs confirmés. La profondeur est relative à la vue d’un nœud donné. [1]
Un Full Node vérifie lui-même les règles. Les noms de fonctions ci-dessous décrivent leur mise en œuvre dans Bitcoin Core. Bitcoin Core ne choisit pas simplement la branche la plus haute ou la plus populaire. Lors de son activation, la chaîne candidate doit respecter les règles de consensus du nœud ; davantage de chainwork ne rend pas valide un bloc invalide. FindMostWorkChain sélectionne le candidat présentant le plus de travail et dont aucune invalidité n’est connue. Cela ne signifie pas encore une validation complète : d’autres contrôles ont lieu lors de la connexion des blocs dans ActivateBestChain. Les branches dont l’invalidité est connue sont écartées. [1]
Un UTXO est une sortie de transaction non dépensée ; l’ensemble UTXO réunit ces sorties disponibles. Les données undo conservent les informations permettant d’annuler les effets d’un bloc. DisconnectTip et la logique de validation qui suit annulent les effets des blocs déconnectés dans l’ordre inverse. Les UTXO dépensés sont restaurés et les sorties créées par le bloc retiré cessent d’être confirmées. C’est pourquoi Bitcoin Core conserve des données d’annulation : il doit pouvoir reconstruire l’ensemble UTXO exactement au point de divergence. [1]
Rollback signifie ici revenir à l’état précédant les blocs déconnectés ; le chainstate est l’état de travail du nœud correspondant à l’historique accepté. Après le retour en arrière, ConnectTip connecte les blocs de la branche au chainwork supérieur dans l’ordre des blocs, de la hauteur la plus basse à la plus haute. Chaque transaction est à nouveau validée par rapport à l’ensemble UTXO reconstruit et aux règles applicables à la hauteur correspondante. Le résultat est un chainstate correspondant à une seule histoire précise, et non un mélange de transactions issues des deux branches. [1]
La Coinbase Transaction est la première transaction du bloc et attribue sa récompense au mineur. La hauteur h indique la position du bloc dans la chaîne. La transaction coinbase fait exception : elle ne retourne pas dans le mempool après la déconnexion du bloc. Selon les règles de consensus, une sortie coinbase créée à la hauteur h peut être dépensée au plus tôt dans le bloc h + 100. Lorsque la pointe est à la hauteur h + 99, le bloc d’origine compte 100 confirmations et la condition de maturité permet d’inclure la dépense dans le bloc suivant. Si une réorganisation retire le bloc contenant la coinbase, la récompense de ce bloc disparaît du chainstate actif. Les transactions ultérieures qui dépendaient de l’histoire retirée peuvent également être invalides. [1] [2] [3]
Voici les noms de fonctions d’une version précise du logiciel, et non des étapes supplémentaires à effectuer dans son portefeuille. Dans Bitcoin Core v29.0, les étapes sont explicites : FindMostWorkChain trouve le candidat au chainwork le plus élevé dont aucune invalidité n’est connue ; ActivateBestChainStep peut déconnecter la pointe actuelle ; ConnectTip vérifie et connecte les blocs alternatifs ; et MaybeUpdateMempoolForReorg réexamine les transactions des blocs déconnectés. L’activation peut révéler l’invalidité du candidat et poursuivre la recherche d’une autre branche. Une réorganisation importante nécessite de traiter davantage de blocs déconnectés et connectés, ce qui peut prolonger le traitement effectué par ActivateBestChain. [1]
Pour une vision complète, lisez aussi Confirmation, Proof of Work, Stale Block, Double dépense, Full Node, UTXO. Cette entrée est également citée par Confirmation, Double dépense, Transaction coinbase, Soft Fork.