LSPS2, o bLIP 52, negocia parámetros, inserta un identificador especial en los datos de pago y, al pasar por el LSP, activa la apertura de un canal privado zero-confirmation y entrega el pago tras descontar la opening fee.
Un Just-in-Time Channel nace solo como respuesta a un pago entrante que llega desde la Lightning Network pública a través de un LSP. El receptor no necesita poseer antes canal, outbound capacity ni fondos on-chain; el coste de la nueva inbound liquidity se paga con el valor del primer pago recibido. [1]
El cliente llama primero a lsps2.get_info y obtiene ofertas con min_fee_msat, tasa proportional en ppm, valid_until, min_lifetime, max_client_to_self_delay y límites de payment size. Envía la oferta elegida y el promise creado por el LSP en lsps2.buy; el LSP puede devolver error si expiró, el pago es insuficiente o falta liquidez. [2]
Un lsps2.buy correcto devuelve jit_channel_scid y lsp_cltv_expiry_delta. El cliente pone el node ID del LSP y ese SCID como único hop del route hint de una invoice BOLT11, o transmite los mismos datos mediante un esquema futuro como blinded path; la expiración no puede superar valid_until y el cliente debe estar conectado al llegar el pago. [1]
Cuando el LSP reconoce jit_channel_scid en un HTLC entrante, inicia el channel establishment estándar de BOLT 2. El canal debe cubrir payment_size_msat menos opening_fee y la reserva, permanece sin anunciar, usa option_scid_alias y puede reenviar el pago como canal zero-confirmation antes de confirmarse la funding transaction. [4]
LSPS2 define dos trust models distintos. En LSP trusts client el proveedor publica primero una funding transaction válida y arriesga que el cliente no revele el preimage; en client trusts LSP puede retrasar el broadcast mientras el cliente libera el preimage y confía en que el LSP creará un funding outpoint válido. [3]
JIT no garantiza entrega incondicional. El pago debe cubrir opening fee, límites y HTLC mínimo; una desconexión antes de funding_signed causa temporary_channel_failure y un prepayment probe ingenuo puede, bajo LSP trusts client, abrir un canal que finalmente no se paga al LSP. [1]
bLIP 52 figura como especificación activa y requiere LSPS0, o bLIP 50, como transporte. El crate de referencia lightning-liquidity ofrece handlers de cliente y servicio para LSPS2, pero documenta el lado servidor como beta; disponer de API no demuestra que una wallet o un LSP estén listos para producción. [5]
La verificación empieza con lsps2.get_info y el cálculo exacto de max(min_fee_msat, proportional fee), además de valid_until, promise, límites del pago, min_lifetime y max_client_to_self_delay. Tras el pago se revisan fee descontada, funding outpoint, parámetros, channel_ready, alias e inbound capacity real; una invoice sola no prueba un canal abierto. [1]
Para obtener la imagen más completa, lee esta entrada junto con Lightning Service Provider, Inbound Liquidity, Payment Channel, Price Channel, BOLT 11, BOLT 12.
01¿Es gratis un Just-in-Time Channel?+
No. El LSP descuenta una opening fee del primer pago entrante. Antes, el cliente debe comprobar en la oferta los componentes mínimo y proporcional, los límites de pago y la vigencia de los parámetros.
02¿Está confirmado on-chain el Just-in-Time Channel antes de recibir el pago?+
Normalmente no. LSPS2 abre un canal zero-confirmation en respuesta al pago y, según el trust model, la funding transaction puede estar solo en mempool o pendiente de broadcast. El cliente debe elegir conscientemente las confirmaciones y el riesgo del LSP que acepta.