Récemment (fin octobre 2023), la communauté Bitcoin a révélé que le Lightning Network pourrait présenter des failles majeures, permettant aux utilisateurs de construire une méthode d’attaque pour voler de l’argent, appelée « Lightning Replacement Cycling Attack ».
J’en ai lu le principe, et le nom chinois peut être traduit par « Lightning Network Cyclic Replacement Transaction Attack ».
Son principe d’attaque est le suivant.
Tout d’abord, expliquez le fonctionnement du Lightning Network :
Alice et Bob ouvrent un canal de paiement, c’est-à-dire qu’ils ouvrent conjointement une adresse de signature 2-2, chacun d’eux détient une clé privée.
Alice et Bob rechargent respectivement 0,5 BTC et 0,6 BTC à cette adresse de signature 2-2 (le montant peut être choisi arbitrairement, je ne suis qu’un exemple), qui se produisent tous deux sur la chaîne principale de Bitcoin, et les mineurs doivent confirmer. De cette façon, l’état initial de ce canal de paiement est que 0,5 BTC appartient à ALICE, 0,6 BTC appartient à BOB, nous enregistrons (ALICE : 0,5 BTC ; bob :0.6btc)。
De cette façon, dans cette adresse de signature 2-2, Alice et Bob peuvent se payer l’un l’autre, par exemple, Alice peut payer BOB 0.1BTC, de sorte que l’état du canal d’état devient 0.4BTC appartient à Alice, 0.7BTC appartient à BOB, (ALICE : 0.4BTC ; bob :0.7btc)。 Et de telles transactions n’ont pas besoin d’être regroupées sur la chaîne principale de Bitcoin, mais se produisent uniquement entre Alice et Bob, ce qu’on appelle un canal de paiement.
Les transferts arbitraires entre Alice et Bob n’ont pas besoin d’être réglés sur la chaîne principale, ce qui permet d’économiser beaucoup de frais de minage et peut être reçu en temps réel, éliminant ainsi le besoin de 10 minutes de confirmation de bloc.
Mais si vous ne pouvez transférer des transactions qu’entre deux personnes, cela ne sert à rien.
Un canal de paiement est également ouvert entre Bob et Carol, et l’état initial est que Bob a 1.0BTC, carol0BTC, qui est enregistré comme (BOB : 1.0BTC ; Carol :0btc)。
À ce moment-là, vous voyez qu’il y a un canal de paiement entre Alice et Bob, et qu’il y a aussi un canal de paiement entre Bob et Carol.
Alice peut alors payer des bitcoins à Carol via Bob.
Le processus de paiement est le suivant : Alice paie 0,1 BTC à Carol, et les changements de statut suivants se produisent dans les deux canaux de paiement ci-dessus
Le changement de statut entre Alice et Bob est (Alice : 0,3 BTC ; BOB : 0,8 BTC)
Le changement d’état entre BOB et CAROL est (BOB : 0,9 BTC ; CAROL : 0,1 BTC)
Cela termine la transaction de transfert de 0,1 BTC d’Alice à Carol.
Lorsque de plus en plus de parties ouvrent le canal de paiement et réalisent une interconnexion mutuelle, un réseau de paiement se forme, que nous appelons le réseau Lightning.
Bien sûr, l’explication technique détaillée est trop compliquée, et ce qui précède est l’explication la plus concise.
Ce qui suit décrit le processus général de l’attaque cyclique de transaction de remplacement du réseau Lightning, et je ne comprends pas les détails techniques détaillés, et ces opcodes, contrats et fonctions sont un peu compliqués.
Les agresseurs sont Alice et Carol, qui conspirent pour attaquer Bob, et Bob est la victime.
Alice paie 0,3 BTC à Carol.
Les canaux d’état initiaux sont les suivants (ALICE : 0,3 BTC ; BOB : 0,8 BTC) et (BOB : 0,9 BTC ; COOL : 0,1 BTC)
Le canal d’état entre Alice et Bob doit être changé en (Alice :0 ; bob : 1.1btc)
Le canal d’état entre BOB et CAROL doit être changé en (BOB : 0,6 BTC ; CAROL : 0,4 BTC)
Alice et Carol ont décidé de s’associer pour escroquer les 0,3 BTC de Bob
Carol n’a pas prétendu confirmer qu’il avait reçu 0,3 BTC d’Alice, c’est-à-dire que Carol n’envoie pas les informations de réception du Lightning Network à BOB. En conséquence, Bob ne serait pas en mesure de réclamer légalement les 0,3 BTC d’Alice au sein du Lightning Network.
À un certain moment, Alice a joué des tours et initie directement la transaction de compensation TX1 sur la chaîne principale de Bitcoin, affirmant qu’il a toujours 0,3 BTC, alors que Bob n’a que 0,8 BTC dans son canal d’état.
Dans la transaction tx1, 0,3 BTC a été envoyé à la propre adresse d’Alice (signature unique), de sorte qu’Alice essayait de voler 0,3 BTC qui ne lui appartenait pas.
Parce que Bob n’a pas reçu le reçu de Carol, Bob ne peut pas prouver (Alice ; bob) dans ce canal d’état doit être remplacé par (alice :0btc ; bob : 1.1btc)
Une fois que TX1 est empaqueté sur la chaîne, c’est-à-dire qu’Alice vole 0,3 BTC, Carol collectera immédiatement 0,3 BTC dans le Lightning Network et enverra le reçu à BOB.
De cette façon, Alice n’a pas réellement envoyé 0,3 BTC à BOB, mais Carol a en fait reçu 0,3 BTC de BOB. Bob s’est donc fait voler 0,3 BTC par Alice et Carol en partenariat.
Notez que lorsqu’Alice initie une transaction de vol de pièces TX1 sur la chaîne principale, Bob a des contre-mesures, c’est-à-dire que l’initiation d’une transaction sur la chaîne principale TX2 prouve qu’Alice triche, mais comme Bob n’a pas reçu le reçu de Carol, la transaction TX2 est toujours assez gênante, mais cela peut être fait théoriquement.
Une fois qu’Alice aura vu TX2, elle utilisera à nouveau la méthode des frais de minage plus élevés pour réinitialiser TX1 afin d’inciter les mineurs à empaqueter TX1 et à rejeter TX2, ce qui est appelé « remplacement ».
À l’heure actuelle, les développeurs disent que la collusion entre Alice et Carol peut en effet rendre plus difficile la légitimation du TX2 de BOB sur les mineurs de la chaîne principale de Bitcoin, et pour prouver plus clairement que TX2 est légitime, le protocole doit être modifié, et c’est un soft fork pour la chaîne principale, ce qui est difficile.
Ce qui précède est le processus général de l’attaque cyclique de la transaction de remplacement Lightning Network, le principe technique spécifique est trop compliqué, je ne comprends pas, je suppose simplement que les détails techniques publiés par le développeur que je vois sur Internet sont corrects.
La méthode d’attaque consiste à prendre en sandwich l’un des deux, et l’échange est naturel et tous les utilisateurs ont ouvert un canal de paiement, donc l’échange va en souffrir.
En fin de compte, j’ai l’impression que ce n’est pas grave, il n’y a pas de bugs dans le logiciel, il y aura un moyen de le corriger.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Comprendre rapidement les attaques par boucle de transaction de remplacement du réseau Lightning
Récemment (fin octobre 2023), la communauté Bitcoin a révélé que le Lightning Network pourrait présenter des failles majeures, permettant aux utilisateurs de construire une méthode d’attaque pour voler de l’argent, appelée « Lightning Replacement Cycling Attack ».
J’en ai lu le principe, et le nom chinois peut être traduit par « Lightning Network Cyclic Replacement Transaction Attack ».
Son principe d’attaque est le suivant.
Tout d’abord, expliquez le fonctionnement du Lightning Network :
Alice et Bob rechargent respectivement 0,5 BTC et 0,6 BTC à cette adresse de signature 2-2 (le montant peut être choisi arbitrairement, je ne suis qu’un exemple), qui se produisent tous deux sur la chaîne principale de Bitcoin, et les mineurs doivent confirmer. De cette façon, l’état initial de ce canal de paiement est que 0,5 BTC appartient à ALICE, 0,6 BTC appartient à BOB, nous enregistrons (ALICE : 0,5 BTC ; bob :0.6btc)。
De cette façon, dans cette adresse de signature 2-2, Alice et Bob peuvent se payer l’un l’autre, par exemple, Alice peut payer BOB 0.1BTC, de sorte que l’état du canal d’état devient 0.4BTC appartient à Alice, 0.7BTC appartient à BOB, (ALICE : 0.4BTC ; bob :0.7btc)。 Et de telles transactions n’ont pas besoin d’être regroupées sur la chaîne principale de Bitcoin, mais se produisent uniquement entre Alice et Bob, ce qu’on appelle un canal de paiement.
Les transferts arbitraires entre Alice et Bob n’ont pas besoin d’être réglés sur la chaîne principale, ce qui permet d’économiser beaucoup de frais de minage et peut être reçu en temps réel, éliminant ainsi le besoin de 10 minutes de confirmation de bloc.
Mais si vous ne pouvez transférer des transactions qu’entre deux personnes, cela ne sert à rien.
Un canal de paiement est également ouvert entre Bob et Carol, et l’état initial est que Bob a 1.0BTC, carol0BTC, qui est enregistré comme (BOB : 1.0BTC ; Carol :0btc)。
À ce moment-là, vous voyez qu’il y a un canal de paiement entre Alice et Bob, et qu’il y a aussi un canal de paiement entre Bob et Carol.
Alice peut alors payer des bitcoins à Carol via Bob.
Le processus de paiement est le suivant : Alice paie 0,1 BTC à Carol, et les changements de statut suivants se produisent dans les deux canaux de paiement ci-dessus
Le changement de statut entre Alice et Bob est (Alice : 0,3 BTC ; BOB : 0,8 BTC)
Le changement d’état entre BOB et CAROL est (BOB : 0,9 BTC ; CAROL : 0,1 BTC)
Cela termine la transaction de transfert de 0,1 BTC d’Alice à Carol.
Bien sûr, l’explication technique détaillée est trop compliquée, et ce qui précède est l’explication la plus concise.
Ce qui suit décrit le processus général de l’attaque cyclique de transaction de remplacement du réseau Lightning, et je ne comprends pas les détails techniques détaillés, et ces opcodes, contrats et fonctions sont un peu compliqués.
Alice paie 0,3 BTC à Carol.
Les canaux d’état initiaux sont les suivants (ALICE : 0,3 BTC ; BOB : 0,8 BTC) et (BOB : 0,9 BTC ; COOL : 0,1 BTC)
Le canal d’état entre Alice et Bob doit être changé en (Alice :0 ; bob : 1.1btc)
Le canal d’état entre BOB et CAROL doit être changé en (BOB : 0,6 BTC ; CAROL : 0,4 BTC)
Alice et Carol ont décidé de s’associer pour escroquer les 0,3 BTC de Bob
Carol n’a pas prétendu confirmer qu’il avait reçu 0,3 BTC d’Alice, c’est-à-dire que Carol n’envoie pas les informations de réception du Lightning Network à BOB. En conséquence, Bob ne serait pas en mesure de réclamer légalement les 0,3 BTC d’Alice au sein du Lightning Network.
À un certain moment, Alice a joué des tours et initie directement la transaction de compensation TX1 sur la chaîne principale de Bitcoin, affirmant qu’il a toujours 0,3 BTC, alors que Bob n’a que 0,8 BTC dans son canal d’état.
Dans la transaction tx1, 0,3 BTC a été envoyé à la propre adresse d’Alice (signature unique), de sorte qu’Alice essayait de voler 0,3 BTC qui ne lui appartenait pas.
Parce que Bob n’a pas reçu le reçu de Carol, Bob ne peut pas prouver (Alice ; bob) dans ce canal d’état doit être remplacé par (alice :0btc ; bob : 1.1btc)
Une fois que TX1 est empaqueté sur la chaîne, c’est-à-dire qu’Alice vole 0,3 BTC, Carol collectera immédiatement 0,3 BTC dans le Lightning Network et enverra le reçu à BOB.
De cette façon, Alice n’a pas réellement envoyé 0,3 BTC à BOB, mais Carol a en fait reçu 0,3 BTC de BOB. Bob s’est donc fait voler 0,3 BTC par Alice et Carol en partenariat.
Notez que lorsqu’Alice initie une transaction de vol de pièces TX1 sur la chaîne principale, Bob a des contre-mesures, c’est-à-dire que l’initiation d’une transaction sur la chaîne principale TX2 prouve qu’Alice triche, mais comme Bob n’a pas reçu le reçu de Carol, la transaction TX2 est toujours assez gênante, mais cela peut être fait théoriquement.
Une fois qu’Alice aura vu TX2, elle utilisera à nouveau la méthode des frais de minage plus élevés pour réinitialiser TX1 afin d’inciter les mineurs à empaqueter TX1 et à rejeter TX2, ce qui est appelé « remplacement ».
Ce qui précède est le processus général de l’attaque cyclique de la transaction de remplacement Lightning Network, le principe technique spécifique est trop compliqué, je ne comprends pas, je suppose simplement que les détails techniques publiés par le développeur que je vois sur Internet sont corrects.
La méthode d’attaque consiste à prendre en sandwich l’un des deux, et l’échange est naturel et tous les utilisateurs ont ouvert un canal de paiement, donc l’échange va en souffrir.
En fin de compte, j’ai l’impression que ce n’est pas grave, il n’y a pas de bugs dans le logiciel, il y aura un moyen de le corriger.