LSP adalah counterparty dan service provider, bukan bagian Bitcoin consensus; client dapat memegang keys sendiri tetapi harus menilai price, availability, channel terms, dan trust model spesifik dari LSPS protocol yang dipakai.
Lightning Service Provider menempatkan liquidity sendiri atau yang diperoleh untuk clients. Umumnya ia membuka channel menuju non-custodial wallet agar memiliki inbound capacity, atau menghubungkan on-chain dan off-chain funds lewat swap; block space, capital, operation, dan risk dikenai harga. [1]
Lightning channel capacity bersifat tetap dan terbagi antara local dan remote balance. Karena itu wallet baru tanpa channel tidak bisa menerima Lightning payment biasa hanya dengan membuat invoice; LSP dapat memberi inbound liquidity tanpa meminta pengguna memilih peer, UTXO, dan funding transaction parameters secara manual. [1]
LSPS0, kini bLIP 50, menyatukan client-LSP communication sebagai JSON-RPC 2.0 melalui Lightning BOLT8 peer-to-peer transport. Semua LSPS messages memakai message ID 37913 dan lsps0.list_protocols mengembalikan extensions yang didukung secara tepat; sebutan LSP tidak menjamin setiap service. [2]
LSPS1 atau bLIP 51 menstandarkan order channel langsung. Client membaca offer, membuat order, memeriksa capacity, price, dan expiry lalu membayar on-chain atau lewat Lightning; specification menyatakan purchase tidak atomic dan client mempercayai LSP untuk menyerahkan channel atau melakukan refund yang ditentukan. [3]
LSPS2 atau bLIP 52 menangani just-in-time channel. Client memperoleh parameters dan menaruh route hint dengan request identifier dalam invoice; saat incoming payment mencapai LSP, provider membuka zero-confirmation channel, memotong opening fee, dan meneruskan sisanya. Client harus terhubung saat itu. [4]
LSP non-custodial tidak memegang private keys client dan membiarkan sisi channel milik client, tetapi operational dependency tetap ada. Provider melihat direct connection dan sebagian payment flow, dapat menolak liquidity, mengubah price dalam offer, atau offline; zero-confirmation channel dan prepaid order juga memiliki risks berbeda. [1]
Standar LSPS0, LSPS1, dan LSPS2 berpindah dari repository awal ke bLIP process sebagai bLIP 50, 51, dan 52 yang aktif. Reference library lightning-liquidity menerapkan LSPS1 dan LSPS2 client handlers serta LSPS2 service handler, tetapi wallet atau node tertentu mungkin hanya mendukung subset dengan terms sendiri. [5]
Sebelum memakai, verifikasi node ID dan connection string LSP, hasil lsps0.list_protocols, capacity dan balance split yang tepat, fee, expiry, confirmations, serta refund policy. Setelah dibuka, periksa funding transaction, channel state, dan inbound capacity aktual; provider logo atau invoice yang berhasil dibuat tidak membuktikannya. [2]
Untuk gambaran yang lebih utuh, baca entri ini bersama Lightning Network, Inbound Liquidity, Payment Channel, Submarine Swap, BOLT 11, Lightning Address. Entri ini juga dirujuk dari Just-in-Time Channels, Trampoline Routing, Bitlifi.
01Apakah Lightning Service Provider otomatis custodial?+
Tidak. LSP dapat membuka channel ke wallet yang memegang keys sendiri dan hanya mengelola sisinya. Client tetap bergantung pada availability, liquidity offer, dan pemenuhan order tertentu.
02Bisakah LSP menerima payment pertama tanpa channel sebelumnya?+
Bisa, jika wallet dan provider mendukung LSPS2 dan payment menutup opening fee. LSP membuka JIT channel ketika pembayaran tiba dan memotong fee; inbound capacity ini tidak gratis atau tanpa syarat.