Un Point Time Locked Contract associe un verrou de point à une voie de remboursement temporisée : compléter une adaptor signature révèle le scalaire correspondant, que le participant précédent utilise pour compléter sa propre signature, tandis que les fonds peuvent être récupérés après expiration du timelock ; c’est une brique de protocole, pas un type standard de paiement Lightning aujourd’hui.
Un HTLC conditionne la branche de réussite à la connaissance de la préimage d’un hash commun ; un PTLC emploie plutôt un point T = t·G et une adaptor signature qui ne peut être complétée qu’avec le scalaire t. La branche temporelle demeure : si le règlement échoue, l’émetteur peut récupérer les fonds après le timeout. [1]
Le destinataire choisit un scalaire secret et publie le point correspondant. Chaque paire de nœuds voisins prépare des signatures incomplètes liées à son verrou de point ; lorsque le destinataire complète la dernière signature, la différence entre l’adaptateur et la signature valide révèle le scalaire et permet le règlement en remontant la route. [1]
L’émetteur peut ajouter des scalaires aléatoires différents pour chaque saut, puis les nœuds soustraient progressivement leurs points. Deux nœuds de routage complices ne voient alors plus le même payment hash comme avec un HTLC classique ; la corrélation par montant, timing, expiration ou topologie reste possible. [4]
BIP 340 donne aux signatures Schnorr une équation linéaire qui facilite la composition des adaptateurs par rapport à ECDSA. Avec une clé agrégée, une dépense on-chain réussie peut ressembler à une signature ordinaire, mais le gain réel d’espace dépend de la construction du canal, du protocole multisignature et de la voie d’urgence. [2]
La sécurité ne repose pas seulement sur le point et le timelock. L’implémentation doit vérifier l’adaptateur, lier correctement la signature au message et à la clé, protéger les nonces, extraire le scalaire sans risque, préserver le remboursement et gérer l’interruption d’un pair ; une erreur peut divulguer une clé ou faire perdre des fonds. [1]
Le BOLT #2 de base actuel décrit toujours update_add_htlc, update_fulfill_htlc et htlc_signature. PTLC ne peut donc pas être présenté comme une fonction interopérable du Lightning Network ordinaire au seul motif que Taproot et BIP 340 sont actifs sur Bitcoin ; il faut des messages, états de canal et implémentations compatibles. [3]
La discussion de développeurs de 2025 souligne l’absence d’outils mûrs et standardisés pour les adaptor signatures avec MuSig2 ainsi que pour les adaptateurs Schnorr autonomes dans les bibliothèques courantes. PTLC est une proposition techniquement élaborée, mais l’état public des outils et spécifications empêche d’affirmer un déploiement large. [5]
PTLC peut améliorer la décorrélation des paiements routés, la preuve de paiement, les paiements atomiques multi-chemins et certains swaps. Il ne résout pas seul la disponibilité des canaux, la liquidité, la perte d’état, le timing malveillant ni l’anonymat complet ; son apport doit être évalué avec l’onion routing et la conception du canal. [4]
Pour une vision complète, lisez aussi HTLC, Schnorr Signature, Lightning Network, Taproot, Payment Channel, Lightning Routing. Cette entrée est également citée par Trampoline Routing.
01Le Lightning Network ordinaire utilise-t-il aujourd’hui PTLC au lieu de HTLC ?+
Pas comme socle interopérable commun. Les spécifications BOLT actuelles définissent encore les messages et signatures HTLC. PTLC exige des outils cryptographiques, des messages, des transitions d’état et un accord entre implémentations ; l’activation de Taproot n’a pas effectué seule cette migration.
02Pourquoi un PTLC est-il plus privé qu’un HTLC ?+
Plusieurs sauts HTLC peuvent porter le même payment hash, donnant aux nœuds complices une valeur directe de corrélation. PTLC permet à chaque saut de modifier le verrou en ajoutant un point local. Le montant, le timing, l’expiration et la position réseau peuvent encore relier le paiement.