HTLC

Anna veut envoyer 20 000 sat à Pavel sur Lightning Network. Sat est l’abréviation de satoshi, la plus petite unité de bitcoin sur la chaîne. Ils n’ont pas de canal commun, mais disposent tous deux d’une connexion adaptée via Eva. Un canal est un accord entre deux participants sur la répartition de bitcoins, que l’on peut mettre à jour sans inscrire chaque paiement dans un bloc. Eva propose à Pavel un paiement conditionnel de 20 000 sat, et Anna propose 20 010 sat à Eva. La différence de 10 sat représente les frais d’Eva dans cet exemple simplifié. Ce sont des changements de soldes liés dans deux canaux, pas une même pièce particulière qui les traverse. Pavel connaît un secret permettant de remplir sa condition ; Eva peut ensuite utiliser cette même valeur auprès d’Anna. Elle n’a donc pas à payer Pavel irrévocablement sur sa seule promesse. Ces montants illustrent le mécanisme, pas des frais habituels ou recommandés. [1]

Pavel prépare pour le paiement un secret aléatoire de 32 octets, la payment_preimage. SHA-256 en calcule le payment_hash. Vérifier qu’une valeur révélée donne la bonne empreinte est facile ; retrouver un secret bien choisi à partir de cette empreinte seule est pratiquement irréalisable. Une facture BOLT 11 ordinaire, une demande de paiement Lightning, contient le hash dans le champ p, pas la preimage. Quand Pavel remplit la condition de paiement, le secret remonte la route et relie les HTLC correspondants. Le payment_secret du champ s est différent : il aide le destinataire à traiter correctement le paiement sans remplacer la preimage. Aucune de ces valeurs n’est une Seed Phrase (les mots permettant de restaurer le portefeuille) ni la clé privée du portefeuille. [1] [4]

Si les deux paiements avaient la même échéance, Pavel pourrait révéler le secret trop tard pour qu’Eva réclame le paiement entrant. Le HTLC venant d’Anna expire donc plus tard que celui qu’Eva propose à Pavel. Cet écart, appelé cltv_expiry_delta, laisse une marge à Eva. Elle en a aussi besoin si une contrepartie cesse de répondre et qu’il faut faire respecter l’accord par des transactions Bitcoin sur la chaîne. La marge se mesure en blocs, pas en minutes exactes, et doit tenir compte des retards et réorganisations. Le logiciel et les règles du canal déterminent son réglage sûr ; une marge trop faible met les fonds en danger. Une réorganisation remplace une partie de la chaîne par une autre branche valide, ce qui peut modifier les confirmations antérieures des transactions. [1]

Dans Lightning, cltv_expiry désigne une hauteur de bloc, sa position dans la chaîne. Ce n’est ni un timestamp Unix (une date et une heure exprimées en nombre de secondes) ni la validité en secondes d’une facture BOLT 11. Lorsque les conditions temporelles sont remplies, la voie timeout peut permettre un règlement sans le secret. Les fonds ne bougent pas seuls : les nœuds Lightning, les logiciels qui gèrent les canaux de paiement, doivent terminer correctement la mise à jour du canal ou utiliser la transaction correspondante sur la chaîne. Une preimage valable ne devient pas non plus inutilisable automatiquement à l’échéance. Si la même sortie, un montant soumis à des règles de dépense, n’a pas déjà été dépensée autrement, plusieurs voies autorisées peuvent entrer en concurrence ; les deux dépenses ne peuvent pas être confirmées dans une même chaîne valide. Agir à temps fait donc partie de la sécurité. [1] [4] [5]

Un HTLC relie des conditions ; il ne permet pas à n’importe quel montant de traverser n’importe quelle route. Eva doit disposer d’assez de fonds dans le sens sortant, la liquidité, et d’une place pour un HTLC en attente supplémentaire. Les limites, les frais ou un nœud indisponible peuvent bloquer le paiement. Tant que la tentative en attente n’est pas correctement résolue, une partie des fonds peut rester immobilisée. Le statut du portefeuille décrit la tentative entière ; un message isolé ne suffit pas à en prouver le résultat. Révéler une preimage ne revient pas à confirmer une transaction Bitcoin. Un paiement Lightning ordinaire réussi se règle par des mises à jour de canaux, sans inscrire chaque paiement dans un nouveau bloc. [1] [3]

Les sections suivantes servent de référence technique. L’état d’un canal indique à qui revient chaque montant et quels HTLC restent en attente. Une commitment transaction est une transaction Bitcoin signée permettant d’imposer cet état sur la chaîne. update_add_htlc propose un ajout ; update_fulfill_htlc annonce l’exécution et update_fail_htlc l’échec. Annoncer la modification ne suffit pas. Par commitment_signed et revoke_and_ack, les parties échangent les signatures du nouvel état et les informations qui rendent dangereuse l’utilisation de l’ancien. Selon BOLT 2, toutes deux doivent s’être engagées irrévocablement sur la modification concernée avant qu’un autre engagement s’appuie dessus. Cet accord entre participants n’est pas une confirmation dans un bloc. Le financement et la fermeture éventuelle du canal reposent, eux, sur des transactions Bitcoin. [1]

Les champs sont les données individuelles d’un message. Un millisatoshi vaut un millième de satoshi : c’est une unité comptable interne à Lightning, pas une fraction que l’on peut dépenser séparément sur la chaîne Bitcoin. La base du message update_add_htlc comprend channel_id, id, amount_msat, payment_hash, cltv_expiry et onion_routing_packet. amount_msat est exprimé en millisatoshi. Le nœud vérifie les limites du canal, la liquidité disponible et les conditions de transfert ; le HTLC sortant possède ses propres paramètres. Il ne doit pas proposer le HTLC suivant avant que l’ajout du HTLC entrant soit irrévocablement confirmé selon BOLT 2. [1]

Onion routing place les instructions de chaque intermédiaire dans des couches chiffrées distinctes. Eva reçoit les indications nécessaires à son étape, pas la liste lisible de tous les participants. Le nœud déchiffre sa propre couche onion et en vérifie l’intégrité. Pour une route ordinaire non masquée, il compare amt_to_forward et outgoing_cltv_value au montant entrant, aux frais et à l’écart temporel exigé. Le paquet ne lui fournit pas la route complète. Cela n’exclut cependant ni la corrélation du trafic ni d’autres déductions d’identité ; le routage onion ne garantit pas un anonymat absolu. [3]

Une sortie associe un montant à des règles de dépense écrites dans le langage Script. Offered et received désignent un HTLC proposé ou reçu du point de vue du participant. La deuxième étape est une transaction suivante ; CHECKSEQUENCEVERIFY (CSV) impose un délai à partir de la confirmation de la sortie dépensée. Une clé de révocation permet de pénaliser la publication d’un ancien état déjà révoqué. BOLT 3 distingue les sorties offered et received ainsi que les voies HTLC-success et HTLC-timeout. La simple connaissance d’un hash ne suffit pas : les signatures, la preimage et les conditions temporelles pertinentes s’appliquent. La sortie locale de deuxième étape comporte le délai CSV to_self_delay, tandis que la bonne clé de révocation permet à la contrepartie d’utiliser la branche de pénalité sans ce délai. Le Script exact dépend du type de canal. [2] [6]

Le trimming signifie qu’un petit HTLC ne devient pas une sortie distincte lorsque l’état du canal est porté sur la chaîne. Dust désigne ces petits montants. Dust exposure mesure leur valeur totale soumise à cette limite. Si le montant après les frais de deuxième étape applicables n’atteint pas dust_limit_satoshis, la transaction de commitment ne crée pas de sortie HTLC. Les règles dépendent du type négocié : option_anchors et zero_fee_commitments n’ont pas ces frais de deuxième étape ; zero_fee_commitments peut diriger la valeur élaguée vers shared_anchor. Une sortie absente ne peut pas être réclamée séparément sur la chaîne. La somme de ces HTLC constitue la dust exposure. [2] [1]

La vérification suivante s’adresse aux opérateurs de nœuds et aux développeurs. Décoder rend les champs d’un enregistrement lisibles ; cela n’envoie rien et ne prouve pas, à lui seul, que toutes les conditions sont satisfaites. Comparez les amount_msat, payment_hash et cltv_expiry entrants et sortants ; vérifiez la preimage avec SHA-256. Suivez aussi commitment_signed, revoke_and_ack et l’état final, pas seulement un message fulfill/fail. En cas d’exécution sur la chaîne, décodez la transaction de commitment réelle, vérifiez l’existence de la sortie, la branche utilisée et HTLC-success/HTLC-timeout. Contrôlez les signatures, les conditions temporelles et les confirmations ; le simple décodage ne prouve pas la validité. [1] [2]