Chemin aveuglé

Le destinataire construit le chemin et le transmet, de sorte que le payeur n'achemine que jusqu'à un point d'introduction public, sans aller plus loin. Une facture BOLT 12 est rejetée si elle ne porte pas de chemin aveuglé, et les sauts aveuglés partagent la charge utile fixe de 1300 octets de l'oignon avec le reste de la route. Si vous publiez une destination Lightning, l'aveuglement empêche que votre identifiant de nœud y figure.

Comment cela fonctionne

Un chemin aveuglé se construit à rebours, par le nœud qui veut être joint et non par le nœud qui paie.

Le destinataire part d'une route réelle vers lui-même et d'une clé éphémère aléatoire, dont il dérive une chaîne de clés de chemin agencées pour que chaque saut puisse calculer la suivante sans qu'on la lui indique. Chaque saut finit par partager un secret ECDH avec le destinataire, et deux choses découlent de ce secret. La première est un facteur d'aveuglement, le HMAC de la chaîne blinded_node_id sous le secret partagé, que le destinataire multiplie par la clé publique de ce saut. Le saut peut toujours signer pour le résultat, car il dérive le même facteur et l'applique à sa propre clé privée, mais personne d'autre ne peut faire correspondre cette clé au graphe publié. La seconde est une clé de chiffrement, utilisée pour sceller un petit bloc d'instructions destiné à ce saut avec ChaCha20-Poly1305 sous un nonce entièrement nul.

Ce qui est publié est court : le point d'introduction en clair, une clé de chemin initiale, puis une liste de clés modifiées chacune associée à son bloc scellé. À l'intérieur d'un bloc se trouvent les champs que ce saut lit : short_channel_id ou next_node_id pour la suite de l'acheminement du paiement, payment_relay pour les frais et le delta CLTV qu'il doit appliquer, payment_constraints pour une expiration maximale et une taille minimale de HTLC, padding, et au dernier saut un path_id.

Trois de ces choix sont défensifs plutôt que fonctionnels. C'est le destinataire, et non le payeur, qui fixe les frais et le timelock de chaque saut aveuglé, de sorte qu'un nœud intermédiaire ne peut pas augmenter son prix en cours de route et observer quels paiements échouent. Il complète chaque bloc à une même longueur et peut ajouter des sauts factices qu'il écarte, de sorte que la longueur réelle n'est pas lisible d'après la forme. Et le path_id contient des données privées, la préimage par exemple, de sorte que le destinataire peut confirmer un chemin qu'il a construit plutôt que d'accepter un chemin qu'un attaquant a envoyé à chaque nœud qu'il soupçonne.

BOLT 12 ajoute une dernière pièce de camouflage. Au lieu de frais par saut aveuglé, une facture porte exactement un blinded_payinfo par chemin : des frais de base en millisatoshis, un taux proportionnel en millionièmes, un delta CLTV agrégé, une taille minimale et maximale de HTLC, et un vecteur de fonctionnalités. La raison indiquée est que le détail par saut révélerait trivialement une non-uniformité qui distingue le chemin.

Pourquoi cela compte quand vous achetez du bitcoin

Les chemins aveuglés changent ce que le milieu du réseau Lightning apprend sur vous, et ne changent rien à ce que votre propre premier saut apprend.

L'aveuglement de route dissimule les sauts après le point d'introduction, et ne dit rien du nœud par lequel votre portefeuille se connecte, celui qui voit vos montants et vos destinations. Phoenix, que ce site note 4,0 parmi ses 41 avis sur des portefeuilles, est d'une honnêteté inhabituelle à ce sujet : la FAQ d'ACINQ indique elle-même que le portefeuille n'offre aucun avantage de confidentialité par rapport à un portefeuille dépositaire hébergé, et qu'ACINQ connaît la destination finale et le montant des paiements. Un chemin aveuglé dans une offre que vous payez n'y change rien.

La conservation supprime entièrement la question. Wallet of Satoshi, que ce site note 2,7 et signale d'un avertissement, détient les clés dans son mode dépositaire, de sorte que les deux extrémités d'un paiement figurent dans ses registres ; la plateforme a cessé de servir les clients des États-Unis le 23 novembre 2023 et a depuis abandonné le service dépositaire dans toute l'Union européenne. Rien de ce qui vous appartient n'est aveuglé quand le paiement ne quitte jamais les livres du prestataire.

Là où l'aveuglement vous apporterait quelque chose, c'est le retrait lui-même. Strike, la plateforme tournée vers Lightning la mieux notée de ce site à 4,6, n'ajoute aucun frais propre sur les transferts et paie vers une destination Lightning que vous fournissez. Remettez-lui une facture BOLT 11 et vous livrez votre nœud : la signature porte un identifiant de récupération, de sorte que la clé du bénéficiaire peut en être récupérée. Une offre place à la place un point d'introduction, partout où le payeur en prend un en charge.

Le coût est diagnostique. Les sauts à l'intérieur d'un chemin aveuglé renvoient des échecs dépourvus de données d'attribution, et le point d'introduction reçoit la consigne d'ajouter un délai aléatoire avant de transmettre une erreur, de sorte que le sondage ne peut pas mesurer la distance du destinataire. Un retrait qui échoue vers une destination aveuglée ne vous apprend donc presque rien : testez-le depuis un portefeuille que vous contrôlez avant de mettre en cause la plateforme.

Dave remet à Alice un chemin passant par Bob et Carol

La spécification Lightning déroule l'idée du chemin aveuglé avec quatre prénoms, ce qui se suit plus vite que l'algèbre.

Dave veut être payé sans qu'Alice sache qu'il s'agit de lui. Il choisit une route vers lui-même en passant par deux nœuds publics, Bob puis Carol, et construit la chaîne de clés de chemin pour que tous les trois dérivent la leur. Puis il scelle trois blocs : un qui dit à Bob de transmettre à Carol, un qui dit à Carol de transmettre à lui, et un pour lui-même portant des métadonnées et le path_id. Enfin il dérive les facteurs qui transforment Bob en Bob prime, Carol en Carol prime et Dave en Dave prime.

Alice reçoit trois lignes : le premier nœud est Bob, voici la première clé de chemin, et voici la séquence Bob prime, Carol prime, Dave prime avec un bloc scellé en regard de chacune. Elle joint Bob par le graphe public ordinaire, ce qui est délibéré : la spécification recommande un tronçon non aveuglé jusqu'au point d'introduction, car il n'a besoin d'aucun soutien des nœuds intermédiaires et renvoie des erreurs lisibles. Bob descelle son instruction, apprend seulement que Carol est la suivante, et transmet la clé de chemin dérivée avec l'oignon. Carol utilise cette clé deux fois, une fois pour modifier l'oignon, qu'Alice a chiffré vers Carol prime et non vers Carol, et une fois pour desceller sa propre instruction. Dave la reçoit en dernier et vérifie le path_id avant d'accepter.

Comptez ce que chacun finit par savoir. Alice connaît Bob. Bob sait qu'il est un point d'introduction et que Carol est la suivante. Carol sait qu'un paiement aveuglé est passé par elle et ne peut pas dire si Dave est le destinataire ou un autre relais. Dave sait tout, car il est le seul à l'avoir construit.

Chemin aveuglé vs indication de route

Un chemin aveuglé et une indication de route répondent à la même question, comment joindre un nœud que le graphe public ne voit pas, et livrent des quantités opposées pour ce faire.

Une indication de route est le champ r d'une facture BOLT 11, et elle est en clair. Chaque entrée porte une clé publique de 264 bits, un identifiant court de canal de 64 bits, des frais de base, un taux proportionnel et un delta CLTV, tous en clair, de sorte que quiconque détient la facture sait à quel nœud bien connecté vous êtes rattaché. Un chemin aveuglé nomme le point d'introduction puis passe dans l'ombre : chaque saut ultérieur est une clé modifiée qui ne correspond à rien dans le graphe, et les frais arrivent agrégés plutôt que détaillés. Les chemins aveuglés reprennent aussi un rôle que les indications de route n'ont jamais eu, celui de tenir lieu des champs payment_secret et payment_metadata d'une facture BOLT 11.

Chemin aveuglé vs routage en oignon

Le routage en oignon dissimule le payeur aux sauts ; un chemin aveuglé dissimule le bénéficiaire au payeur.

Dans le routage en oignon ordinaire, l'expéditeur choisit chaque saut dans le graphe public et empile une couche de chiffrement par saut, de sorte qu'aucun nœud de transmission n'apprend qui paie ni où il se situe dans la route. L'expéditeur connaît toujours toute la route, y compris l'identifiant de nœud réel de la destination, ce qui convient pour payer une boutique et ne sert à rien pour publier une destination réutilisable. L'aveuglement de route fournit la moitié manquante sans rien remplacer : un paiement par un chemin aveuglé reste un oignon, et l'aveuglement est une modification de clé ajoutée par-dessus. Les deux sont assez séparables pour qu'un destinataire qui ne veut pas de cette confidentialité puisse construire un chemin à un seul saut ne contenant que lui-même et livrer quand même son identifiant de nœud.