Explication de la relecture des transactions et de la protection contre la relecture avec Hard Forks

Comprendre la relecture et la cryptographie

Quand une pièce fait un hard fork, deux chaînes de blocs identiques existent jusqu'à ce que des modifications soient apportées à l'une des chaînes. Pour éviter les replays de transactions (les transactions effectuées sur une chaîne étant diffusées sur l'autre), au moins une chaîne doit implémenter une protection contre la relecture (les développeurs d'une chaîne doivent changer le format des transactions pour les rendre uniques). ^{[1] [2]}

Si la protection contre la relecture n'est pas ajoutée, alors toute transaction effectuée sur une chaîne peut être « rejouée » (rediffusée) sur l'autre. Après tout, la seule différence entre les deux chaînes (si rien n'est modifié par les développeurs) est qu'il existe deux copies de la chaîne et que les mineurs effectuent des transactions sur chaque chaîne séparément. Les adresses sont les mêmes, les clés sont les mêmes, le format des transactions est le même, etc… et cela laisse place à des exploits.

Lorsqu'un acteur malveillant exploite une chaîne avec un manque de « replay protection, » par exemple en diffusant une transaction destinée à une chaîne sur l'autre chaîne, c'est ce qu'on appelle une "attaque par rejeu".

Les attaques par rejeu peuvent entraîner une perte de fonds en raison de l'envoi à la fois de la pièce d'origine et de la pièce fourchue à la même adresse.

Dans les cas où il existe une fourchette litigieuse (comme BCH et BSV) ou une fourchette mise en œuvre à la hâte (comme ETH et ETC), la protection contre la relecture peut ne pas être ajoutée tout de suite et l'utilisateur devra se protéger.

Un utilisateur peut, en théorie, se protègent contre les attaques par rejeu en « divisant les pièces ». Cependant, il n'y a pas de solution de fractionnement de pièces infaillible et parfaite que j'ai trouvée qui puisse être recommandée avec une confiance à 100%.

Ainsi, un utilisateur inexpérimenté peut vouloir attendre que la protection contre la relecture soit confirmée pour envoyer des pièces après un fork afin de limiter le nombre de choses qui peuvent mal tourner (ceci est particulièrement important si vous avez déjà réclamé vos pièces fork mais n'avez pas déplacé votre solde d'origine après le bloc d'instantanés avant la mise en service du MainNet).

Avec tout ça couvert, il y a une tonne de détails techniques et de spécificités que je n'ai pas abordés ci-dessus.

Pour une compréhension complète de tout le replay, vous devez vraiment creuser le fonctionnement des blockchains et comprendre certains aspects techniques du code. Dit clairement, cela sort du cadre du site.

Pour l'utilisateur moyen, la meilleure protection contre les attaques par rejeu consiste à 1. utiliser un service de garde qui honorera un fork, puis ne le déplacera pas vers un autre portefeuille tant que la protection de rejeu n'aura pas été confirmée, ou 2. être maître de vos clés privées, déplacer vos fonds après l'instantané mais avant la mise en service du nouveau MainNet, réclamer la fourchette, puis attendre de déplacer des fonds sur l'une ou l'autre chaîne jusqu'à ce que la protection contre la relecture soit confirmée, ou 3. être en contrôle de vos clés privées et ne rien faire du tout jusqu'à ce que la protection contre la relecture soit confirmée.

L'essentiel ici est le suivant, vous ne pouvez pas rencontrer de problèmes de replay sauf si vous partagez vous diffusez une transaction, donc si vous ne diffusez pas une transaction (envoyer ou dépenser), vous ne mettrez pas en péril vos pièces dans une fourchette dépourvue de protection contre la relecture.

ASTUCE :La protection contre la relecture n'est pas la seule chose à protéger avec les forks. Pour réclamer une fourchette, vous devez importer vos clés dans le portefeuille de la pièce fourchue. Pour le faire en toute sécurité, vous devez déplacer votre solde d'origine… si vous le faites après la mise en ligne du MainNet de la pièce fourchue, vous avez un catch-22, car vous devez envoyer vos pièces à une nouvelle adresse !

ASTUCE :Des attaques par rejeu peuvent également se produire si l'on utilise les mêmes clés sur un TestNet que sur un MainNet. En général, une attaque par rejeu effectue une transaction sur une blockchain, et en le répétant malicieusement ou frauduleusement sur une autre blockchain. ^[3] Cela n'a rien à voir avec une fourchette dure, bien que les fourches dures et la protection contre la relecture soient le sujet de la page.

Hardfork sans protection contre la relecture expliquée | Bitcoin Cash (11-15-18).