Formation N°3 – Lightning Network

Explication technique du Lightning Network par Fanis Michalakis

100% gratuit – 12 chapitres + Quizz

#8 – HTLC

Formation Lightning Network de Fanis Michalakis

Résumé :

Dans un système de routage classique, Alice 100 000 -> 30 000 Susie 250 000 -> Bob 0, comment s’assurer qu’Eden ne triche pas et respecte bien sa part du contrat ?

HTLC – Hashed Time Locked Contract

HTLC est donc un contact de paiement où l’on peut déverrouiller uniquement avec un secret. S’il n’est pas dévoilé, alors le contrat expire.  C’est donc un paiement conditionnel. Comment sont-ils utilisés ?

 

  1. Bob génère un secret S (la préimage) et en calcule le hash r= hash(s)
  2. Bob envoie une invoice à Alice avec notamment « r »
  3. Alice envoie un HTLC de 40 000 satoshis à Susie avec pour condition de révéler « s’ » tel que hash(s’)=r
  4. Susie envoie un HTLC similaire à Bob
  5. Bob déverrouille le HTLC de Susie en lui montrant « s »
  6. Susie déverrouille le HTCL d’Alice en lui montrant « S »

 

Si Bob est offline et ne relève jamais le secret qui lui donne la légitimité pour recevoir l’argent, dans ce cas le HTLC va expirer après un certain nombre de bloc.

 

Les HTLC expire dans l’ordre du dernier au premier : donc expiration Susie – Bob puis Alice -Susie.

Comme ça, si Bob revient, ça ne change rien. Dans le cas contraire, si Alice annule alors que Bob revient, ce sera le bordel et des gens peuvent avoir travaillé pour rien.

Bon et alors, la question c’est : en cas de clôture, il se passe quoi ? En fait, nos transactions d’engagement sont encore plus complexes. Il faut représenter la balance intermédiaire si jamais le canal se fait fermer.

 

Il y a donc un HTLC-out de 40 000 satoshis (avec les limitations vues avant) dans la transaction d’engagement via un output n°3 

Alice a donc dans la transaction d’engagement :

Out-put n°1 : 60 000 SAT pour Alice via un Timelock et clé de révocation (ce qui lui reste)

Out_put n°2 : 30 000 qui appartienne déjà à Susie

Out-put n°3 : 40 000 en HTLC

 La transaction d’engagement d’Alice est avec un HTCL-out car elle envoie et Susie un HTLC-in car elle reçoit.

 Donc si l’on publie cette transaction d’engagement, Susie peut récupérer l’argent du HTCL avec l’imagine « s ». Si elle n’a pas la préimage, Alice récupère l’argent une fois que le HTCL expire.

Pensez des out-put comme différents paiements avec différentes conditions.

Une fois le paiement passé (expiration ou exécution), l’état du canal change et la transaction avec HTCL n’existe plus. On retourne avec quelque chose de classique.

 En cas de fermeture coopérative : on arrête les paiements et donc on attend l’exécution des transferts/HTCL, la transaction est légère donc moins chère car il y a maximum 1 ou 2 outputs.

 Si fermeture forcée : on publie avec tous les HTLC en cours, ça devient donc très lourd et très coûteux. Et c’est le bordel.

 

Fanis Michalakis

Fanis Michalakis

Spécialiste Lightnin Network

Etudiant à @CentraleMarsThunder Wizard @KryptoSphere_• Web Peón @StrikeInFrance • On my way to Vollmünzenstapelzielerreichung • #Bitcoin, Unión, Libertad