Deuxième Thread de JohnOnChain consacré aux dispositifs anti-triche du Lightning Network. La première partie est disponible ici. Notre fraudeur n’en démord et va affiner sa stratégie. Il sait que le verrou temporel est limité et fonction de la taille du canal. Ça tombe bien il a un autre canal avec notre victime. Le verrou temporel est de 144 blocs (1 journée). Il suffit donc que le fraudeur s’assure que sa victime ait une panne importante l’empêchant de se reconnecter en moins de 24 heures. Le plan est sans accroc (pense-t-il). Voici l’état du canal (c’est le premier) :– 445K sats du côté du fraudeur – 554K sats du côté de la victime Le fraudeur va faire une sauvegarde de son fichier d’état (channel.db) avant qu’une
Topics:
La rédaction considers the following as important:
This could be interesting, too:
Andrew Throuvalas writes Jack Dorsey’s Bitcoin Mining Chip Is Now Complete
Anthonia Isichei writes Venezuela to Accelerate Crypto Usage in Response to Reimposed US Oil Sanctions: Report
Dimitar Dzhondzhorov writes Polkadot’s Latest Advancements: Ecosystem Weekly Recap
Chayanika Deka writes Bitcoin (BTC) Fails to Attract Safe-Haven Flows: Kaiko
Deuxième Thread de JohnOnChain consacré aux dispositifs anti-triche du Lightning Network. La première partie est disponible ici.
Notre fraudeur n’en démord et va affiner sa stratégie. Il sait que le verrou temporel est limité et fonction de la taille du canal. Ça tombe bien il a un autre canal avec notre victime. Le verrou temporel est de 144 blocs (1 journée). Il suffit donc que le fraudeur s’assure que sa victime ait une panne importante l’empêchant de se reconnecter en moins de 24 heures. Le plan est sans accroc (pense-t-il).
Voici l’état du canal (c’est le premier) :
– 445K sats du côté du fraudeur
– 554K sats du côté de la victime
Le fraudeur va faire une sauvegarde de son fichier d’état (channel.db) avant qu’une opportunité s’ouvre. Il fait son paiement de 100K sats. Nouvelle balance :
– 345 K sats côté fraudeur
– 654 K sats côté victime.
Le nœud de la victime tombe à nouveau. Cette fois, la panne est plus grave et il lui faut au moins une semaine pour réparer son nœud. Du côté du fraudeur, il attend patiemment. Après une journée de panne, il tente sa chance. Il va restaurer son fichier d’état (channel.db) :
…et forcer la fermeture du canal. Voici la transaction de triche :
Ca semble perdu d’avance pour la victime… Mais après la première tentative de fraude, elle a choisi d’utiliser les services d’un gardien (aka WatchTower). Ce sont des nœuds Lightning qui ont pour rôle de sauvegarder les canaux et surveiller les tentatives de fraude. Ce n’est pas automatique, un nœud lightning doit se connecter manuellement à une watchtower. Voici la doc de lnd.
Ni une ni deux, la watchtower détecte la tentative de triche et puni à nouveau le fraudeur. Voici les logs de la watchtower :
Et la transaction justice publiée par la Watchtower. C’est la même chose que le premier scénario sauf qu’ici, c’est la Watchtower qui a fait le taf.
Il n’est pas nécessaire que tous les nœuds utilisent une watchtower. Un fraudeur ne peut pas savoir d’avance si victime en utilise une. Le risque pour lui est immense puisqu’en cas d’échec, il perdra tous ses fonds (dans le canal). Cependant, il ne semble pas exister de ressource publiant les watchtowers publics. Créer une watchtower implique de fournir des ressources (CPU et disque) sans pouvoir (encore) être rémunéré. Ce n’est pas problématique à ce jour, mais ça le deviendra à l’avenir.
Sur le même sujet : Comprendre le Lightning Network – Episode 5 : le mécanisme anti-triche par Fanis Michalakis
A propos de l’auteur
Bitcoiner, testeur et bidouilleur, JohnOnChain est avant tout un expert et un aventurier du bitcoin. A suivre absolument ;sur Twitter.
Soutenez ses expérimentations en lui envoyant un tip : https://lnbits.openchain.fr/lnurlp/31