LSPS2, ou bLIP 52, negocia parameters, inclui um identifier especial nos payment data e, ao passar pelo LSP, aciona a abertura de um private zero-confirmation channel e entrega o payment após descontar a opening fee.
Um Just-in-Time Channel nasce apenas em resposta a um incoming payment vindo da public Lightning Network por um LSP. O destinatário não precisa possuir antes channel, outbound capacity ou on-chain funds; o custo da nova inbound liquidity é pago com o primeiro payment recebido. [1]
O client chama lsps2.get_info e recebe offers com min_fee_msat, proportional rate em ppm, valid_until, min_lifetime, max_client_to_self_delay e payment size limits. Ele envia a offer escolhida e o promise criado pelo LSP em lsps2.buy; pode haver error se expirou, se o payment é pequeno demais ou se falta liquidity. [2]
Um lsps2.buy bem-sucedido retorna jit_channel_scid e lsp_cltv_expiry_delta. O client põe LSP node ID e esse SCID como único hop do route hint numa BOLT11 invoice, ou transmite os mesmos dados por um esquema futuro como blinded path; expiry não pode passar valid_until e o client precisa estar conectado quando o payment chega. [1]
Quando o LSP reconhece jit_channel_scid num incoming HTLC, inicia o channel establishment padrão BOLT 2. O channel deve comportar payment_size_msat menos opening_fee e reserve, fica unannounced, usa option_scid_alias e pode encaminhar o payment como zero-confirmation channel antes da confirmação da funding transaction. [4]
LSPS2 descreve dois trust models. Em LSP trusts client, o provider primeiro publica uma valid funding transaction e arrisca o client não liberar o preimage; em client trusts LSP, pode adiar o broadcast enquanto o client libera o preimage e confia que o LSP criará um valid funding outpoint. [3]
JIT não é delivery incondicional. O payment deve cobrir opening fee, limits e minimum HTLC; disconnect antes de funding_signed causa temporary_channel_failure, e um naive prepayment probe em LSP trusts client pode abrir um channel pelo qual o LSP não recebe payment. [1]
bLIP 52 é active specification e exige LSPS0, ou bLIP 50, como transport. O reference crate lightning-liquidity oferece client e service handlers para LSPS2, mas a documentation chama o service-side support de beta; API disponível não comprova production readiness de wallet ou LSP. [5]
Verification começa com lsps2.get_info e o cálculo exato de max(min_fee_msat, proportional fee), além de valid_until, promise, payment limits, min_lifetime e max_client_to_self_delay. Depois do payment, conferir deducted fee, funding outpoint, channel parameters, channel_ready, alias e actual inbound capacity; invoice sozinha não prova open channel. [1]
Para ter uma visão mais completa, leia este verbete junto com Lightning Service Provider, Inbound Liquidity, Payment Channel, Price Channel, BOLT 11, BOLT 12.
01Um Just-in-Time Channel é grátis?+
Não. O LSP desconta a opening fee do primeiro incoming payment. O client deve verificar antes os componentes minimum e proportional, payment limits e validity period dos parameters.
02O Just-in-Time Channel já está confirmado on-chain antes de receber o payment?+
Normalmente não. LSPS2 abre um zero-confirmation channel em resposta ao payment e, conforme o trust model, a funding transaction pode estar só no mempool ou aguardar broadcast. O client deve escolher conscientemente confirmation threshold e LSP risk.