Un Hashed Timelock Contract associe une condition de hash à un verrou temporel. Lightning utilise payment_hash, un montant et cltv_expiry pour chaque HTLC. La payment_preimage correspondante permet de remplir les conditions en remontant la route ; le timeout permet un règlement alternatif. La sécurité dépend aussi des états confirmés des canaux, des signatures et d’une réaction à temps.
Le destinataire fournit une payment_preimage de 32 octets dont le SHA-256 correspond à payment_hash. BOLT 11 indique le hash dans le champ p de la facture ; le hash seul ne révèle pas le secret. La même preimage relie les conditions de plusieurs HTLC successifs. payment_secret, dans le champ s, est une autre donnée et ne remplace pas la preimage. [BOLT 2 — Channel state and HTLC handling] [BOLT 11 — Payment hash and invoice expiry]
Dans Lightning, cltv_expiry désigne une hauteur de bloc absolue, pas un timestamp Unix ni la durée de validité en secondes d’une facture BOLT 11. Lorsque les conditions temporelles sont atteintes, la dépense par timeout peut devenir disponible. Une preimage valide ne cesse toutefois pas automatiquement de fonctionner ; deux dépenses concurrentes de la même sortie ne peuvent pas toutes deux être confirmées dans une même chaîne valide. Le remboursement n’est pas automatique. [BOLT 2 — Channel state and HTLC handling] [BOLT 11 — Payment hash and invoice expiry] [BIP 65 — CHECKLOCKTIMEVERIFY]
update_add_htlc propose l’ajout ; update_fulfill_htlc ou update_fail_htlc traitent respectivement l’exécution ou l’échec. Un message isolé ne termine pas le changement d’état : commitment_signed et revoke_and_ack assurent les signatures du nouvel état et la révocation de l’ancien des deux côtés. Un paiement ordinaire ne nécessite pas de nouvelle inscription dans un bloc, mais le financement et la fermeture du canal utilisent des transactions Bitcoin. [BOLT 2 — Channel state and HTLC handling]
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. [BOLT 2 — Channel state and HTLC handling]
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. [BOLT 4 — Onion routing and payload validation]
Le HTLC entrant doit expirer plus tard que le HTLC sortant suivant. L’écart cltv_expiry_delta donne à l’intermédiaire une marge pour obtenir la preimage, réagir si la contrepartie est indisponible et obtenir une confirmation sur la chaîne. Il intègre les risques de retard et de réorganisation ; un nombre de blocs ne garantit pas un nombre fixe de minutes. Une marge trop faible met les fonds en danger. [BOLT 2 — Channel state and HTLC handling]
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. [BOLT 3 — HTLC transaction scripts and trimming] [BIP 112 — CHECKSEQUENCEVERIFY]
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. [BOLT 3 — HTLC transaction scripts and trimming] [BOLT 2 — Channel state and HTLC handling]
Le même secret relie les conditions le long de la route, mais accepter l’offre ne garantit pas à lui seul un paiement achevé. La liquidité, le nombre de HTLC disponibles, les frais, les expirations et les règles de routage peuvent arrêter le paiement. Une exécution ou un échec sûrs exigent le bon ordre des changements et un traitement à temps. Révéler la preimage n’est pas la même chose que confirmer une transaction Bitcoin. [BOLT 2 — Channel state and HTLC handling] [BOLT 4 — Onion routing and payload validation]
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é. [BOLT 2 — Channel state and HTLC handling] [BOLT 3 — HTLC transaction scripts and trimming]
Pour une vision complète, lisez aussi Lightning Network, Payment Channel, Timelock, Hachage cryptographique, CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY. Cette entrée est également citée par Timelock, Payment Channel, Liquidité Lightning, Lightning Routing.