LSPS2 यानी bLIP 52 parameters तय करता है, payment data में विशेष identifier रखता है और LSP से गुजरने पर private zero-confirmation channel खोलकर opening fee काटने के बाद payment देता है।
Just-in-Time Channel तभी बनता है जब public Lightning Network से incoming payment LSP होकर आता है। Receiver को पहले channel, outbound capacity या on-chain funds रखने की जरूरत नहीं; नई inbound liquidity की cost पहले मिले payment से चुकती है। [1]
Client पहले lsps2.get_info बुलाकर min_fee_msat, ppm में proportional rate, valid_until, min_lifetime, max_client_to_self_delay और payment size limits वाली offers लेता है। चुनी offer और LSP का बनाया promise lsps2.buy में भेजता है; expiry, छोटा payment या liquidity की कमी पर error मिल सकता है। [2]
सफल lsps2.buy से jit_channel_scid और lsp_cltv_expiry_delta मिलते हैं। Client LSP node ID और इस SCID को BOLT11 invoice के route hint का अकेला hop बनाता है या blinded path जैसे future scheme से वही data देता है; expiry valid_until से आगे नहीं और payment आने पर client connected होना चाहिए। [1]
Incoming HTLC में jit_channel_scid पहचानकर LSP standard BOLT 2 channel establishment शुरू करता है। Channel में payment_size_msat minus opening_fee और reserve की जगह होनी चाहिए, वह unannounced रहता है, option_scid_alias इस्तेमाल करता है और funding transaction confirm होने से पहले zero-confirmation channel से payment forward कर सकता है। [4]
LSPS2 दो trust models बताता है। LSP trusts client में provider पहले valid funding transaction publish करता है और client के preimage न छोड़ने का risk लेता है; client trusts LSP में provider broadcast रोक सकता है जबकि client preimage छोड़कर valid funding outpoint बनने पर भरोसा करता है। [3]
JIT unconditional delivery नहीं है। Payment को opening fee, limits और minimum HTLC cover करना होगा; funding_signed से पहले disconnect पर temporary_channel_failure होता है और naive prepayment probe LSP trusts client में ऐसा channel open करा सकता है जिसका payment LSP को न मिले। [1]
bLIP 52 active specification है और transport के लिए LSPS0 यानी bLIP 50 मांगता है। Reference crate lightning-liquidity LSPS2 के client और service handlers देता है, पर documentation service-side support को beta कहती है; API होना wallet या LSP की production readiness साबित नहीं करता। [5]
Verification lsps2.get_info और max(min_fee_msat, proportional fee) के सही calculation से शुरू होता है, साथ में 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 पहले incoming payment से opening fee काटता है। Client को offer में minimum और proportional fee, payment limits और parameters validity period पहले जांचना चाहिए।
02क्या payment मिलने से पहले Just-in-Time Channel on-chain confirmed होता है?+
आमतौर पर नहीं। LSPS2 payment के जवाब में zero-confirmation channel खोलता है; trust model के अनुसार funding transaction केवल mempool में या broadcast से पहले हो सकती है। Client confirmation threshold और LSP risk खुद चुनता है।