Secret de paiement

Le secret de paiement de Lightning fonctionne comme un mot de passe propre à chaque facture, que le payeur renvoie avant que le nœud récepteur accepte les fonds. Le BOLT 11 lui attribue la lettre d'étiquette s, fixe sa longueur à 52 caractères bech32 et demande au lecteur de rejeter toute facture qui arrive sans lui. Pour vous, c'est la raison pour laquelle un nœud de routage qui a vu votre hash de paiement ne peut pas dire que le paiement s'est terminé dans votre portefeuille.

Comment cela fonctionne

Un secret de paiement est créé par le portefeuille récepteur, jamais par le payeur, et il reste scellé dans l'oignon jusqu'à ce que le paiement atteigne son dernier saut.

Le BOLT 11 le définit comme un champ étiqueté de type 16, écrit avec la lettre s et une data_length fixe de 52. Ces 52 caractères bech32 portent 260 bits, soit une valeur de 32 octets plus le remplissage, et celui qui rédige une facture doit en inclure exactement un. Le lecteur doit faire échouer le paiement si un champ de longueur fixe n'a pas la bonne longueur, et de nouveau si aucun champ s valide n'est présent.

Le payeur recopie la valeur dans la charge utile de l'oignon destinée au dernier nœud, que le BOLT 4 appelle enregistrement TLV de type 8, payment_data, contenant le secret de 32 octets et un montant total_msat. Seule la destination peut ouvrir cette couche, si bien que les sauts intermédiaires ne la voient jamais, contrairement au hash de paiement sur lequel tous verrouillent leurs HTLC.

La vérification à l'autre bout est volontairement peu informative. Un secret qui ne correspond pas à celui attendu pour ce hash de paiement, ou qui est exigé et absent, fait échouer le HTLC avec incorrect_or_unknown_payment_details, erreur PERM|15, la même réponse que reçoit un hash de paiement inconnu. Le BOLT 4 explique la fusion : l'ancien couple, PERM|16 incorrect_payment_amount et 17 final_expiry_too_soon, permettait à un nœud de transfert de renvoyer des paiements avec le même hash à des valeurs bien plus basses et de lire la réponse pour confirmer qu'il avait trouvé la destination.

La prise en charge ne se négocie plus. Le BOLT 9 classe les bits de fonctionnalité 14 et 15, payment_secret, comme ASSUMED, et les bits 16 et 17, basic_mpp, en dépendent.

Où le voir

Dans une chaîne lnbc moderne, vous pouvez repérer un secret de paiement à la suite qui commence par sp5 et se poursuit sur 52 caractères bech32.

Dans les vecteurs de test du BOLT 11, cette suite est zyg3 répété douze fois puis zygs, ce qui encode un secret dont les 32 octets valent tous 0x11. Vous ne saisissez jamais un secret de paiement : seuls celui qui rédige la facture et le portefeuille payeur manipulent la valeur.

C'est dans les paiements en plusieurs parties que ce champ est utile. Quand aucune route unique ne détient assez de liquidité et que la facture propose basic_mpp, le BOLT 4 permet à un portefeuille de répartir le montant sur plusieurs HTLC partageant un même hash de paiement, et chaque partie doit porter le secret et devrait s'accorder sur total_msat. Le récepteur ne règle rien tant que le total n'est pas arrivé, et devrait attendre au moins 60 secondes après le premier HTLC avant de faire échouer l'ensemble avec un mpp_timeout. Ainsi, un retrait Lightning plus important depuis une application qui privilégie Lightning comme Strike, qui reste en attente une minute puis revient, peut être un ensemble de HTLC incomplet qui expire plutôt que de l'argent perdu. Que votre propre portefeuille assemble ces parties, comme le fait Phoenix en exécutant un véritable nœud Lightning sur le téléphone, ou qu'un dépositaire s'en charge sur un serveur que vous ne contrôlez pas, le secret les marque comme un seul paiement.

Secret de paiement vs hash de paiement

Le hash de paiement et le secret de paiement sont tous deux des champs de 256 bits dans une même facture BOLT 11, et la différence tient à qui peut les voir. Chaque saut apprend le hash, car chacun verrouille son HTLC transmis dessus, tandis que seul le dernier nœud apprend le secret, qui voyage dans la couche la plus interne de l'oignon. Le hash répond à la question de savoir si le paiement a été réglé, et la préimage qui l'ouvre est le reçu. Le secret répond à la question de savoir si le payeur travaille à partir de la facture que vous avez écrite, ce qu'un hash ne peut pas faire, étant visible de tous sur la route. Dans l'encodage, ils se ressemblent comme des jumeaux : étiquette p et étiquette s, toutes deux de 52 caractères, toutes deux rejetées à toute autre longueur.