Un LSP est une contrepartie et un prestataire, pas une composante du consensus Bitcoin ; le client peut garder ses clés mais doit évaluer prix, disponibilité, conditions du canal et trust model précis du protocole LSPS utilisé.
Un Lightning Service Provider déploie sa propre liquidité ou celle qu’il a obtenue pour ses clients. Il ouvre le plus souvent un canal vers une wallet non-custodial afin de fournir inbound capacity, ou relie fonds on-chain et off-chain par un swap ; block space, capital, exploitation et risque sont facturés. [1]
La capacité d’un canal Lightning est fixe et répartie entre local et remote balance. Une nouvelle wallet sans canal ne peut donc pas recevoir un paiement ordinaire en créant seulement une invoice ; un LSP fournit inbound liquidity sans obliger l’utilisateur à choisir manuellement peer, UTXO et paramètres de funding transaction. [1]
LSPS0, désormais bLIP 50, uniformise la communication client-LSP en JSON-RPC 2.0 sur le transport peer-to-peer Lightning BOLT8. Tous les messages LSPS utilisent message ID 37913 et lsps0.list_protocols renvoie les extensions exactement prises en charge ; l’étiquette LSP ne garantit donc pas chaque service. [2]
LSPS1, ou bLIP 51, standardise la commande directe d’un canal. Le client lit l’offre, crée un order, vérifie capacité, prix et expiration, puis paie on-chain ou via Lightning ; la spécification précise que l’achat n’est pas atomique et que le client fait confiance au LSP pour livrer le canal ou effectuer le refund prévu. [3]
LSPS2, ou bLIP 52, traite le just-in-time channel. Le client obtient les paramètres et place dans l’invoice un route hint avec l’identifiant de requête ; quand le paiement arrive au LSP, celui-ci ouvre un zero-confirmation channel, déduit l’opening fee et transmet le reste. Le client doit alors être connecté. [4]
Un LSP non-custodial ne détient pas les private keys du client et lui laisse son côté du canal, mais une dépendance opérationnelle demeure. Le fournisseur voit la connexion directe et une partie du flux, peut refuser la liquidité, modifier le prix dans l’offre ou être offline ; zero-confirmation channel et commande prépayée ont des risques distincts. [1]
Les standards LSPS0, LSPS1 et LSPS2 ont rejoint le processus bLIP comme bLIP 50, 51 et 52 actifs. La bibliothèque de référence lightning-liquidity implémente les client handlers LSPS1 et LSPS2 et un service handler LSPS2, mais une wallet ou node donnée peut ne prendre en charge qu’un sous-ensemble avec ses propres conditions. [5]
Avant usage, vérifier node ID et connection string du LSP, résultat de lsps0.list_protocols, capacité exacte et partage de balance, fee, expiration, confirmations et refund policy. Après ouverture, vérifier funding transaction, channel state et inbound capacity réelle ; logo ou invoice créée ne prouvent aucune de ces propriétés. [2]
Pour une vision complète, lisez aussi Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. Cette entrée est également citée par Just-in-Time Channels, Trampoline Routing, Bitlifi.
01Un Lightning Service Provider est-il automatiquement custodial ?+
Non. Un LSP peut ouvrir un canal vers une wallet qui garde ses clés et ne gérer que son côté. Le client dépend encore de sa disponibilité, de son offre de liquidité et de l’exécution de la commande.
02Un LSP permet-il de recevoir le premier paiement sans canal préalable ?+
Oui, si wallet et fournisseur prennent en charge LSPS2 et si le paiement couvre l’opening fee. Le LSP ouvre un JIT channel à l’arrivée du paiement et déduit le coût ; l’inbound capacity n’est ni gratuite ni inconditionnelle.