LSPS2, ou bLIP 52, négocie les paramètres, place un identifiant spécial dans les données de paiement et déclenche, lors du passage par le LSP, l’ouverture d’un canal privé zero-confirmation puis la remise du paiement après déduction de l’opening fee.
Un Just-in-Time Channel n’est créé qu’en réponse à un paiement entrant venant du Lightning Network public via un LSP. Le destinataire n’a donc besoin à l’avance ni de canal, ni d’outbound capacity, ni de fonds on-chain ; le coût de la nouvelle inbound liquidity est payé sur la valeur du premier paiement reçu. [1]
Le client appelle d’abord lsps2.get_info et reçoit des offres contenant min_fee_msat, un taux proportional en ppm, valid_until, min_lifetime, max_client_to_self_delay et les limites de payment size. Il transmet l’offre choisie et le promise produit par le LSP dans lsps2.buy ; une erreur peut survenir si elle a expiré, si le paiement est trop faible ou si la liquidité manque. [2]
Un lsps2.buy réussi renvoie jit_channel_scid et lsp_cltv_expiry_delta. Le client met le node ID du LSP et ce SCID comme seul hop du route hint d’une invoice BOLT11, ou transmet les mêmes données par un futur schéma tel qu’un blinded path ; l’expiration ne doit pas dépasser valid_until et le client doit être connecté à l’arrivée du paiement. [1]
Quand le LSP reconnaît jit_channel_scid dans un HTLC entrant, il lance le channel establishment BOLT 2 standard. Le canal doit couvrir payment_size_msat moins opening_fee et la réserve, reste non annoncé, utilise option_scid_alias et peut relayer le paiement comme canal zero-confirmation avant confirmation de la funding transaction. [4]
LSPS2 décrit deux trust models. En mode LSP trusts client, le fournisseur publie d’abord une funding transaction valide et risque que le client ne libère pas le preimage ; en mode client trusts LSP, il peut attendre avant broadcast pendant que le client libère le preimage et compte sur un funding outpoint valide. [3]
JIT n’est pas une livraison inconditionnelle. Le paiement doit couvrir opening fee, limites et HTLC minimal ; une déconnexion avant funding_signed entraîne temporary_channel_failure, et un prepayment probe naïf peut, avec LSP trusts client, ouvrir un canal pour lequel le LSP ne sera finalement pas payé. [1]
bLIP 52 est une spécification active et exige LSPS0, ou bLIP 50, comme transport. Le crate de référence lightning-liquidity fournit des handlers client et service pour LSPS2, mais sa documentation qualifie le service de beta ; disposer de l’API ne prouve donc pas qu’une wallet ou un LSP soit prêt pour la production. [5]
La vérification commence par lsps2.get_info et le calcul exact max(min_fee_msat, proportional fee), puis valid_until, promise, limites de paiement, min_lifetime et max_client_to_self_delay. Après paiement, contrôler fee déduite, funding outpoint, paramètres, channel_ready, alias et inbound capacity réelle ; une invoice seule ne prouve pas un canal ouvert. [1]
Pour une vision complète, lisez aussi Lightning Service Provider, Inbound Liquidity, Payment Channel, Price Channel, BOLT 11, BOLT 12.
01Un Just-in-Time Channel est-il gratuit ?+
Non. Le LSP déduit une opening fee du premier paiement entrant. Le client doit vérifier avant cela les parts minimale et proportionnelle, les limites du paiement et la durée de validité des paramètres.
02Le Just-in-Time Channel est-il confirmé on-chain avant la réception du paiement ?+
En général non. LSPS2 ouvre un canal zero-confirmation en réponse au paiement et, selon le trust model, la funding transaction peut seulement être dans le mempool ou attendre son broadcast. Le client doit choisir consciemment les confirmations et le risque LSP acceptés.