Glossaire / Lightning et couche 2
Keysend
- Qu'est-ce que Keysend ?
- Keysend envoie un paiement Lightning sans facture : le payeur génère la préimage de 32 octets, la hache en hachage de paiement et transmet le secret à l'intérieur de l'oignon.
Keysend inverse le flux Lightning habituel, où le destinataire choisit un secret et publie son hachage dans une facture. Le secret de l'expéditeur voyage dans l'enregistrement TLV personnalisé 5482373484, un nombre pair, que le BOLT 1 oblige un nœud qui ne connaît pas keysend à rejeter plutôt qu'à ignorer. Vous pouvez payer une clé publique de nœud brute sans aller-retour, et vous renoncez au reçu cryptographique qu'une facture aurait laissé.
Comment cela fonctionne
Keysend repose sur la moitié la plus stricte d'une règle du BOLT 1 : un lecteur écarte un enregistrement TLV inconnu de type impair et poursuit, mais doit faire échouer tout le flux sur un enregistrement pair inconnu.
Les identifiants de type inférieurs à 2^16 sont réservés aux BOLT et tout ce qui va de 2^16 et au-delà est libre pour les enregistrements personnalisés, et le BOLT 1 dit de choisir un nombre impair quand les nœuds ordinaires doivent ignorer les données, un nombre pair quand ils doivent les rejeter. Le bLIP-3 note que 5482373484 a été choisi au hasard par l'implémentation lnd d'origine, et il se termine par un quatre, donc keysend s'est retrouvé du côté du rejet. C'est pourquoi il a besoin d'un bit de fonctionnalité : les nœuds volontaires annoncent 54/55, nommé keysend, qui dépend de var_onion_optin, et le bLIP-3 dit que les expéditeurs devraient le rechercher plutôt que d'envoyer à l'aveugle et de regarder l'échec.
La tâche de l'expéditeur, exposée dans le bLIP-3, est courte. Générer une valeur aléatoire cryptographiquement sûre de 32 octets, la placer dans cet enregistrement, et définir le payment_hash dans update_add_htlc à son SHA-256. Ne réutilisez jamais une préimage, et ne réutilisez jamais celle d'une facture que vous avez déjà payée. Le paquet est obscurci à chaque saut, donc un saut ne récupère que l'adresse du suivant et personne entre les deux ne voit l'enregistrement. Le nœud final hache la valeur qu'il trouve, la vérifie contre le hachage qu'on lui a demandé d'accepter, et règle.
Le refus est délibérément discret. Le BOLT 4 a une réponse littérale pour une charge utile qu'un nœud n'a pas comprise, PERM|22 invalid_onion_payload, qui peut même nommer le type TLV fautif. Le bLIP-3 demande aux destinataires de renvoyer PERM|15 incorrect_or_unknown_payment_details à la place, afin qu'un keysend refusé soit indiscernable d'un hachage de paiement que le nœud n'a jamais émis.
Où le voit-on
Keysend est la plomberie sous les boosts de podcast.
Le bLIP-10 définit un second enregistrement, de type 7629169, choisi à l'origine par Breez, portant un bloc JSON plat attaché au paiement keysend : le titre du podcast, l'épisode, ts pour la position de lecture en secondes, action défini à boost ou stream, et un message facultatif, qui est ce qui fait un boostagram. La diffusion en continu minute par minute définit seconds_back à 60. Cet enregistrement est impair, c'est pourquoi le bLIP-10 écarte la compatibilité descendante : un hôte qui ignore les métadonnées conserve quand même les sats. Il existe parce qu'un keysend à lui seul ne dit rien au destinataire, donc une application doit nommer l'émission elle-même.
Le même manque tient keysend à l'écart du parcours d'achat. Un retrait depuis une plateforme d'échange vous remet une facture ou vous en demande une, parce que la plateforme doit rattacher le paiement à votre compte, et le mot n'apparaît dans aucun des 63 comptes rendus de plateformes d'échange ni des 41 avis de portefeuilles sur ce site. Le bLIP-3 énonce honnêtement le compromis : il s'attend à ce que keysend cède la place à un paiement spontané mieux conçu, nommant les offers et AMP, et énumère ce que vous perdez entre-temps, la preuve de paiement et tout mot à dire du bénéficiaire sur l'expiration CLTV finale.
Keysend vs adresse Lightning
Keysend et une adresse Lightning permettent tous deux de payer quelqu'un qui ne vous a jamais remis de facture, et un seul des deux saute vraiment la facture. Taper user@example.com envoie votre portefeuille sur une recherche HTTPS qui renvoie une facture BOLT11 fraîche, donc le destinataire a quand même choisi la préimage et vous vous retrouvez avec un reçu adossé à sa signature. Keysend n'a besoin d'aucune requête web ni serveur, seulement de la clé publique de nœud de 33 octets et d'une route vers elle, et il ne vous laisse rien à prouver ensuite, parce que le secret était le vôtre depuis le début. Si vous deviez un jour avoir besoin de montrer que vous avez payé, prenez la facture.