Lightning Watchtower

Anna et Pavel ont un canal de paiement : leurs fonds sont immobilisés ensemble dans Bitcoin, et les paiements Lightning en modifient la répartition. Pavel paie Anna, les deux acceptent les nouveaux soldes et révoquent l’ancien état. Puis Anna perd sa connexion. Si Pavel publiait l’ancien état, il pourrait tenter de récupérer de l’argent déjà dépensé. Anna peut prévoir un Lightning Watchtower pour ce cas. Son nœud lui transmet à l’avance des données chiffrées pour protéger les états révoqués. Lorsque le service reconnaît la transaction correspondante dans la chaîne, il peut diffuser une transaction de récupération sans qu’Anna soit connectée. Il ne paie pas à sa place et ne répare pas son nœud. [1] [8]

Chaque répartition convenue possède une commitment transaction : une transaction signée permettant de fermer le canal sur la chaîne Bitcoin. Lors d’une mise à jour, les participants échangent les informations qui permettent de sanctionner la publication de l’état précédent, désormais révoqué. Nous décrivons ici ce modèle de canal à pénalité. Si Pavel utilise l’état actuel valide, il peut fermer le canal unilatéralement pendant l’absence d’Anna. Le Watchtower n’a pas à empêcher cette fermeture. Il agit contre un état révoqué précis, que Pavel l’ait publié volontairement ou par erreur depuis une ancienne sauvegarde. C’est la révocation qui compte, pas l’âge de la transaction. [1] [8]

Une Seed Phrase est une sauvegarde sous forme de mots qui permet de retrouver les clés privées nécessaires pour signer les paiements. LND est l’un des logiciels permettant de faire fonctionner un nœud Lightning. Anna ne donne au service ni sa Seed Phrase ni les clés privées de tout son portefeuille. Elle fournit des données et des signatures limitées à une intervention précise ; LND appelle cet ensemble JusticeKit. La transaction de récupération, appelée justice transaction, restitue les fonds protégés selon des conditions préparées à l’avance. Le Watchtower n’obtient pas pour autant le droit de dépenser les autres bitcoins d’Anna. Dans le modèle sans rémunération du service, les frais de la transaction Bitcoin sont déduits du montant protégé. Le code prévoit aussi des types avec rémunération de la tour, mais cela ne prouve pas qu’un opérateur donné propose un service payant. [3] [4] [5]

Pour aider, le Watchtower doit réellement recevoir les données nécessaires. Saisir son adresse dans les réglages ou voir une tâche en attente d’envoi ne suffit pas. Le client, la partie du nœud d’Anna qui communique avec la tour, doit recevoir des accusés de réception des mises à jour. La connexion peut tomber, un accord de stockage appelé session peut atteindre sa capacité, ou une sauvegarde peut être refusée. Anna doit donc aussi suivre les envois non reçus et les erreurs. Même des données acceptées ne garantissent pas le succès : la tour doit suivre la bonne chaîne et faire confirmer son intervention dans un bloc à temps. [6] [8]

Si Anna perd son appareil, elle ne le restaurera pas à partir du Watchtower. Le service surveille l’utilisation abusive d’états révoqués ; il ne restaure pas son portefeuille et ne résout pas un vol de clés. LND utilise Static Channel Backup (SCB) pour récupérer les canaux. Avec la graine du portefeuille, cette sauvegarde aide à récupérer les fonds en fermant les canaux, pas à reprendre exactement au dernier état du nœud. SCB n’est ni une copie de chaque mise à jour ni le paquet chiffré envoyé à la tour. Démarrer une ancienne base channel.db sans la bonne procédure de récupération est particulièrement dangereux : le nœud pourrait publier son propre état révoqué. Suis la documentation de sauvegarde de ton portefeuille et de sa version précise. [7]

Une sortie de transaction indique un montant et les conditions permettant de le dépenser. La protection repose sur un délai : celui qui publie son état du canal ne peut pas dépenser immédiatement sa sortie différée. BOLT 3 nomme cette sortie to_local et le délai to_self_delay. CSV est la règle qui mesure ce délai en blocs depuis la confirmation de la sortie. L’autre participant peut utiliser la voie de pénalité sans cette attente s’il possède la bonne clé de révocation. Le Watchtower dispose ainsi d’une avance pour agir. À la fin du délai, la voie de pénalité ne disparaît pas, mais l’autre participant peut lui aussi dépenser les fonds. Le résultat dépend de celle des dépenses incompatibles qui sera valablement confirmée. Diffuser la transaction de récupération ne suffit donc pas, et un nombre de blocs n’est pas un nombre exact d’heures. [1] [9]

Avant de choisir un service, vérifie ce qu’il protège réellement. Les HTLC sont des paiements conditionnels qui peuvent rester en attente dans le canal ; surveiller les soldes ne prouve pas leur couverture. Dust désigne ici une sortie trop petite pour être incluse dans cette transaction. Le backupTask vérifié de LND v0.21.3-beta prépare les sorties to_local et to_remote existantes et non dust du commitment révoqué. Il n’inclut pas une protection générale de toutes les sorties HTLC ; la documentation correspondante la présente comme une extension future. Bitcoin Script est le langage qui exprime les conditions de dépense d’une sortie. Pouvoir dépenser une sortie par la voie de pénalité ne signifie pas qu’une tour donnée a reçu les données nécessaires ni qu’elle peut mettre cette protection en œuvre. [3] [5]

Le paquet chiffré n’exige pas que la tour lise en permanence tous les soldes d’Anna. Elle recherche une correspondance avec un identifiant court et déchiffre les données grâce à la transaction reconnue. La suite est une référence technique pour une version précise de LND ; txid désigne l’identifiant d’une transaction et blob un paquet de données. Dans LND v0.21.3-beta, BreachHint correspond aux 16 premiers octets du SHA-256 du txid binaire. BreachKey est obtenu par SHA-256 de la concaténation de ce même txid binaire deux fois de suite. Il ne s’agit ni des 16 premiers caractères du txid affiché ni simplement de sa première moitié. Le client chiffre le JusticeKit ; connaître la transaction correspondante permet de dériver la clé et de déchiffrer les données. [2] [3]

Exploiter une tour pour les autres et faire surveiller ses propres canaux sont deux tâches distinctes. Ces réglages concernent les opérateurs LND ; RPC est l’interface par laquelle le programme reçoit des commandes. LND distingue watchtower.active pour le serveur de wtclient.active pour le client. Activer uniquement le serveur ne configure pas la sauvegarde de ses propres canaux auprès d’une autre tour. lncli tower info affiche pubkey, listeners et uris du serveur ; lncli wtclient add enregistre une tour pour le client. La clé publique de la tour diffère de celle du nœud Lightning. Vérifie le réseau, l’accessibilité de l’adresse et la prise en charge RPC dans la compilation utilisée. [5]

L’intervention doit payer de la place dans un bloc Bitcoin. Le satoshi est la plus petite unité du bitcoin. L’octet virtuel mesure la taille d’une transaction en tenant compte du poids différent de ses composants. Le tarif est exprimé en satoshis par octet virtuel de transaction, pas en pourcentage des fonds protégés. Dans LND v0.21.3-beta, le champ sweep_sat_per_vbyte des politiques et sessions indique un taux en sat/vB. Les frais réduisent le montant restitué. backupTask peut rejeter un état de valeur trop faible ou aux paramètres de session inadaptés ; toute tâche préparée n’est pas une sauvegarde admissible. Modifier ultérieurement les réglages ne prouve pas que les transactions déjà signées ont changé, et un taux insuffisant peut retarder l’intervention. [3] [6]

Une seconde tour ne peut aider si la première tombe en panne que si elle a elle-même reçu les données nécessaires. L’indépendance concerne aussi les connexions et les opérateurs, pas seulement les noms des services. Plusieurs tours indépendantes et une surveillance propre peuvent limiter l’effet d’une panne unique. Vérifie toutefois quelles mises à jour précises chaque tour a acceptées ; plusieurs adresses enregistrées ne prouvent pas à elles seules la réplication de tous les états. Des machines, réseaux et emplacements distincts réduisent les défaillances communes. Les blobs chiffrés et les connexions authentifiées limitent la visibilité des soldes, mais ne suppriment ni les métadonnées, ni la visibilité de la fréquence des mises à jour, ni le risque de corrélation. [5] [8]

Distingue surtout une mise à jour envoyée d’une mise à jour réellement reçue. Ces commandes et champs servent de référence aux administrateurs LND ; l’accusé de réception d’une sauvegarde n’est pas une confirmation de transaction dans un bloc. Utilise lncli wtclient towers, lncli wtclient tower, lncli wtclient stats et lncli wtclient policy. Dans LND v0.21.3-beta, distingue num_backups de num_pending_backups ; le second champ désigne les sauvegardes en attente de confirmation par la tour. num_failed_backups dans la réponse stats compte les sauvegardes échouées non confirmées. Les statistiques couvrent la période depuis le démarrage du client. active_session_candidate indique un candidat pour des sessions, pas une preuve de protection complète. [6]

Une bonne configuration est le point de départ. Un essai doit couvrir toute la séquence, de la détection d’un état révoqué à la récupération des fonds protégés ; ne le réalise pas avec ton argent réel. Contrôle la version précise du client et de la tour, le type de canal et de session pris en charge, l’actualité des données, les frais et la synchronisation avec la chaîne. Teste la réaction dans un environnement de test isolé ; une fermeture unilatérale ordinaire (force close) ne prouve pas une intervention contre un état révoqué. Le résultat est attesté par la publication de l’état révoqué (breach), la justice transaction construite et ses sorties confirmées. Une démonstration réussie ne garantit ni la disponibilité future ni l’élimination de tous les risques de Lightning. [1] [3] [6]