Un LSP es contraparte y proveedor, no parte del consenso Bitcoin; el cliente puede conservar sus propias claves, pero debe evaluar precio, disponibilidad, condiciones del canal y el trust model concreto del protocolo LSPS usado.
Un Lightning Service Provider despliega liquidez propia o adquirida para sus clientes. Suele abrir un canal hacia una wallet non-custodial para darle inbound capacity, o conectar fondos on-chain y off-chain mediante un swap; cobra por block space, capital, operación y riesgo. [1]
La capacidad de un canal Lightning es fija y se divide entre local y remote balance. Por eso una wallet nueva sin canal no puede recibir un pago Lightning normal solo creando una invoice; un LSP aporta inbound liquidity sin que el usuario elija manualmente peer, UTXO y parámetros de funding transaction. [1]
LSPS0, ahora bLIP 50, unifica la comunicación cliente-LSP como JSON-RPC 2.0 sobre el transporte peer-to-peer Lightning BOLT8. Todo mensaje LSPS usa message ID 37913 y lsps0.list_protocols devuelve las extensiones exactas admitidas; llamarse LSP no garantiza todos los servicios. [2]
LSPS1, o bLIP 51, normaliza un pedido directo de canal. El cliente carga la oferta, crea un order, comprueba capacidad, precio y expiración y paga on-chain o por Lightning; la especificación dice expresamente que la compra no es atómica y que se confía en el LSP para entregar el canal o efectuar el refund previsto. [3]
LSPS2, o bLIP 52, resuelve un just-in-time channel. El cliente obtiene parámetros e incluye en la invoice un route hint con el identificador; cuando el pago entrante llega al LSP, este abre un zero-confirmation channel, descuenta la opening fee y reenvía el resto. El cliente debe estar conectado entonces. [4]
Un LSP non-custodial no guarda las private keys del cliente y le deja su lado del canal, pero sigue habiendo dependencia operativa. El proveedor ve la conexión directa y parte del flujo, puede rechazar liquidez, cambiar precios dentro de la oferta o estar offline; un zero-confirmation channel y un pedido prepagado tienen riesgos distintos. [1]
Los estándares LSPS0, LSPS1 y LSPS2 pasaron del repositorio original al proceso bLIP como bLIP 50, 51 y 52 activos. La librería de referencia lightning-liquidity implementa client handlers LSPS1 y LSPS2 y un service handler LSPS2, pero una wallet o node concreta puede admitir solo una parte y aplicar condiciones propias. [5]
Antes de usarlo hay que verificar node ID y connection string del LSP, resultado de lsps0.list_protocols, capacidad y reparto de balance exactos, fee, expiración, confirmations y refund policy. Tras abrir, se comprueban funding transaction, channel state e inbound capacity real; logo o invoice creada no demuestran esas propiedades. [2]
Para obtener la imagen más completa, lee esta entrada junto con Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. También enlazan con esta entrada Just-in-Time Channels, Trampoline Routing, Bitlifi.
01¿Es un Lightning Service Provider automáticamente custodial?+
No. Un LSP puede abrir un canal a una wallet que conserva sus claves y gestionar solo su lado. El cliente aún depende de su disponibilidad, oferta de liquidez y cumplimiento del pedido.
02¿Puede un LSP recibir el primer pago sin canal previo?+
Sí, si wallet y proveedor admiten LSPS2 y el pago cubre la opening fee. El LSP abre un JIT channel al llegar el pago y descuenta la tarifa; no es inbound capacity gratuita ni incondicional.