LSPS2, або bLIP 52, погоджує parameters, додає спеціальний identifier до payment data і при проходженні через LSP запускає відкриття private zero-confirmation channel та передачу payment після віднімання opening fee.
Just-in-Time Channel виникає лише у відповідь на incoming payment, що приходить із public Lightning Network через LSP. Одержувачу не потрібні заздалегідь channel, outbound capacity чи on-chain funds; вартість нової inbound liquidity сплачується з першого отриманого payment. [1]
Client спершу викликає lsps2.get_info й отримує offers з min_fee_msat, proportional rate у ppm, valid_until, min_lifetime, max_client_to_self_delay та payment size limits. Вибрану offer і створений LSP promise він надсилає в lsps2.buy; можлива error, якщо offer спливла, payment замалий або liquidity бракує. [2]
Успішний lsps2.buy повертає jit_channel_scid і lsp_cltv_expiry_delta. Client додає LSP node ID і цей SCID як єдиний hop route hint до BOLT11 invoice або передає ті самі дані майбутньою схемою на кшталт blinded path; expiry не перевищує valid_until, а client мусить бути підключений під час payment. [1]
Коли LSP розпізнає jit_channel_scid у incoming HTLC, він запускає стандартний BOLT 2 channel establishment. Channel має вмістити payment_size_msat мінус opening_fee і reserve, лишається unannounced, використовує option_scid_alias і може переслати payment як zero-confirmation channel до підтвердження funding transaction. [4]
LSPS2 описує два trust models. У LSP trusts client provider спершу публікує valid funding transaction і ризикує, що client не відкриє preimage; у client trusts LSP provider може затримати broadcast, тоді як client відкриває preimage і покладається на створення valid funding outpoint. [3]
JIT не гарантує delivery без умов. Payment має покрити opening fee, limits і minimum HTLC; disconnect до funding_signed спричиняє temporary_channel_failure, а naive prepayment probe у LSP trusts client може відкрити channel, за який LSP зрештою не отримає payment. [1]
bLIP 52 має active status і потребує LSPS0, або bLIP 50, як transport. Reference crate lightning-liquidity дає client і service handlers для LSPS2, але documentation називає service-side support beta; наявність API не доводить production readiness конкретної wallet чи LSP. [5]
Verification починається з lsps2.get_info і точного max(min_fee_msat, proportional fee), а також valid_until, promise, payment limits, min_lifetime і max_client_to_self_delay. Після payment перевіряють deducted fee, funding outpoint, channel parameters, channel_ready, alias і actual inbound capacity; invoice сама не доводить open channel. [1]
Для повної картини прочитайте також Lightning Service Provider, Inbound Liquidity, Payment Channel, Price Channel, BOLT 11, BOLT 12.
01Чи Just-in-Time Channel безкоштовний?+
Ні. LSP віднімає opening fee з першого incoming payment. Client має заздалегідь перевірити minimum і proportional частини fee, payment limits та validity period параметрів.
02Чи Just-in-Time Channel підтверджений on-chain до отримання payment?+
Зазвичай ні. LSPS2 відкриває zero-confirmation channel у відповідь на payment, а залежно від trust model funding transaction може бути лише в mempool або ще чекати broadcast. Client свідомо обирає confirmation threshold і LSP risk.