LSPS0/1/2/5 · JIT Channels · Liquidity Market

Lightning Service Provider
モバイル LN を支えるインフラ層

モバイル wallet ユーザーは 常時オンライン・on-chain 資金管理・gossip graph 保持を自前で行うのが困難。 LSP (Lightning Service Provider) はチャネル管理・流動性提供・routing をアウトソース可能にする事業者層。 JIT channel（payment 着信時にチャネルを開く）、liquidity ads、splicing 等の primitive を組み合わせ、 非カストディアルのままユーザー体験を CEX 並みに引き上げる。LSPS0–5 の標準仕様で実装間 interop も確立中。

SpecLSPS0 / 1 / 2 / 5 (BLIP)

非カストディアル秘密鍵はユーザー保持

主要事業者ACINQ / Breez / Voltage / OLYMPUS / Lightspark

統合 walletPhoenix / Breez / Mutiny / Zeus

JIT

payment 着信時に channel open

LSPS0–5

標準化された相互運用 spec

Non-custodial

資金保持なし

5+ providers

主要 LSP 事業者

§ 1 · The Problem

モバイル LN ユーザーが直面する 5 つの課題

① チャネル開設のハードル

on-chain TX + 初期資金（BTC）が必要。新規ユーザーが「いきなり LN 受信」できない。

② Inbound liquidity ゼロ問題

新規開設チャネルは送信側容量しかなく、受信不能。submarine swap や rebalancing が必要。

③ 残高偏りの解消

頻繁な送受信で channel balance が片寄る → 定期的に rebalancing 必須。

④ Gossip graph の管理

routing には数十 MB の channel graph が必要。モバイル端末では困難。

⑤ 常時オンライン要求

受信には wallet がオンライン必須。スマホはバッテリー・通信制限がある。

💡 LSP の本質

LSP は これら 5 課題のすべてをアウトソース可能にする。ユーザーの秘密鍵は wallet 内に残るため 非カストディアル。 LSP の役割はあくまで「チャネルの相手方としての機能提供」であり、サービスの対価として手数料を取る。

LSP ≠ Custodial Wallet

⛔ Custodial wallet (Wallet of Satoshi 等)

事業者が秘密鍵保有
ユーザーは 資産を預けている
事業者破綻 = 資産消失リスク
UX は最良だが信託モデル

✅ LSP-backed wallet (Phoenix / Breez 等)

ユーザーが秘密鍵保有
LSP は channel 相手方のみ
LSP が消失しても force-close で回収可能
Custodial 並みの UX を非カストディアル維持

§ 2 · Architecture Layers

LSP がはまる 4 層構造

モバイル user → LSP → routing nodes → Bitcoin の階層関係。各層の役割と境界を可視化。

📱 User Layer

モバイル wallet (Phoenix / Breez / Mutiny) — 秘密鍵保持、UI 担当

Non-custodial

🛎️ LSP Layer

channel management, JIT open, liquidity provisioning, routing 起点

Service provider

🌐 Routing Layer

public LN nodes — payment forwarding, gossip graph host

Public network

⛓ Bitcoin Layer

on-chain settlement, funding, force-close

Layer 1

各層の責任分担

機能	User	LSP	Routing	Bitcoin
秘密鍵管理	✓	—	—	—
Channel open / close	consent	✓	—	settle
Inbound liquidity	—	✓	—	—
Pathfinding	—	✓ (trampoline)	forward	—
Gossip graph	—	✓	✓	—
Always-online	✗	✓	✓	✓

§ 3 · LSPS Specifications

LSP 標準化の系譜 — LSPS0 / 1 / 2 / 5

2023 年から策定された LSP Spec series。複数事業者が同一 wallet ドキュメントで動作するための相互運用性を確立。

LSPS0

Common schemas / Transport

BOLT 8 transport 上の JSON-RPC over LN message を定義。すべての LSPS の共通基盤。

LSPS1

Channel request

ユーザーが LSP から 事前に channel を購入する API。Inbound liquidity を有償で確保。

LSPS2

JIT Channel ⭐ 最重要

incoming payment 着信時に その場で channel を開く。fee は payment から差し引く。Phoenix の中核。

LSPS5

Webhook registration

LSP から user wallet への push 通知。受信予定通知、async payment delivery 用。

LSPS の RPC フロー例 (LSPS2 JIT)

# 1. User asks LSP for fee quote
User → LSP: {"method": "lsps2.get_info", "params": {}}
LSP  → User: {
  "opening_fee_params_menu": [
    {"min_fee_msat": 10_000, "proportional": 100, # 100 ppm
     "valid_until": "2026-05-12"},
    ...
  ]
}

# 2. User accepts a quote and gets a virtual SCID
User → LSP: {"method": "lsps2.buy", "params": {"opening_fee_params": {...}}}
LSP  → User: {"jit_channel_scid": "abc:def:ghi"}

# 3. User publishes invoice with this SCID as route hint
invoice = bolt11_create(amount=50000, route_hint=[(LSP_pubkey, jit_channel_scid)])

# 4. Sender pays. LSP receives the HTLC, then opens channel + forwards.
# Channel is funded with the payment amount minus the LSP's fee.

§ 4 · JIT Channel — The Killer Feature

「払い込み即開設」のフロー詳解

Step 0 / 6

Press Play to walk through the JIT channel flow.

UX として何が起きるか

User experience (Phoenix / Breez):
  1. Bob installs wallet → "Receive" button → invoice 表示
  2. Sender が invoice 払う → 数秒
  3. Bob's wallet: "+50,000 sats received (net 49,000 sats after LSP fee)"

What actually happened:
  - LSP opened a new channel on-chain right at that moment
  - The 1,000 sats fee covers: on-chain TX, LSP service, opportunity cost
  - Bob now has a usable channel for future payments too
  - All non-custodial — Bob can force-close any time

✅ JIT channel の利点

初心者でもすぐ受信可能 — 事前 channel 開設不要
UX が CEX 並み（"receive" ボタンを押すだけ）
非カストディアル維持
受信 = channel 開設なので将来の送信にも使える

⚠ 制約と課題

初回受信は 数千 sats の fee（on-chain cost + LSP margin）
LSP に 受信予定 SCID が露出（privacy 課題）
Prepayment probing で誤発火リスク（mitigation 進行中）
LSP の 競争市場 がまだ未成熟

§ 5 · Liquidity Ads & Channel Marketplace

LSP が「inbound liquidity を売る市場」

LSPS1 + Liquidity Ads (BOLT proposal) で、事前に inbound liquidity を購入できる仕組み。Pool / Magma / Amboss / OLYMPUS などのマーケットプレイスを通じて、ユーザーが期間と容量を指定して購入する。

Liquidity Ads の流れ

# 1. LSP が liquidity ad を gossip で publish
liquidity_ad = {
  capacity: 1_000_000_sats,
  duration: 30_days,
  lease_fee_rate: 100_ppm,         # per day
  channel_fee_max_base_msat: 1000,
  channel_fee_max_ppm: 50
}

# 2. ユーザーが購入
user.lease_inbound(
  capacity=500_000,
  duration=30,
  to_lsp=lsp_pubkey
)
# LSP が dual-funded channel を open + 期間 commit

# 3. LSP は期間中、その capacity を空けて待つ
#    違反 (early close, low fee 設定) → on-chain penalty

📊 Inbound Liquidity Cost Calculator

容量 (sats)

1,000,000 sats

期間 (日)

30 days

レート (ppm/day)

100 ppm/day

3,000 sats

lease fee total

100 sats

daily cost

3.65%

implicit APR

USD (BTC@$60k)

主要 Liquidity Marketplace

Marketplace	Operator	方式	特徴
Lightning Pool	Lightning Labs	Auction	初期の market、batch auction model
Amboss Magma	Amboss	Marketplace	UI フレンドリー、最大手
OLYMPUS	ZEUS / OLYMPUS	LSP + market	JIT + 事前 lease 統合
Voltage	Voltage	Hosted LSP	node hosting + LSP セット
Lightspark Inbound	Lightspark	Enterprise	大口・規制対応志向

§ 6 · Provider Comparison

主要 LSP 5 社の比較 — クリックで詳細

ACINQ (Phoenix)

FRANCE · 2014–

Eclair 開発元 / Phoenix wallet 自社運営

Breez

USA · 2018–

Breez SDK / non-custodial mobile

Voltage

USA · 2020–

Hosted LND + LSP / enterprise focus

Amboss / Magma

USA · 2021–

Liquidity marketplace, analytics

OLYMPUS by ZEUS

USA · 2023–

Self-hostable LSP + ZEUS wallet

Lightspark

USA · 2022– (Marcus 創設)

Enterprise / regulated payment rails

機能サポート比較

LSP	JIT Channel	Splicing	BOLT 12	Async Pay	API	Wallet
ACINQ	✓	✓	✓	✓	Phoenix native	Phoenix
Breez	✓	部分	議論中	部分	Breez SDK	Breez
Voltage	✓	—	—	—	REST API	—
Amboss	部分	—	—	—	Magma API	—
OLYMPUS	✓	✓	✓	✓	LSPS1/2/5	ZEUS
Lightspark	✓	—	—	—	Enterprise API	—

§ 7 · LSP Economics

LSP のビジネスモデルと潜在課題

収益源

1. Channel open fee

JIT channel 開設時の on-chain fee + service margin。典型 1–3% (受信額に比例)。

2. Routing fee

ユーザーの送信を中継する際の base + ppm fee。1 sat + 数 ppm が典型。

3. Liquidity lease fee

事前 lease 型 inbound liquidity の販売。期間 × 容量 × ppm/day。

4. Premium services

Webhook (LSPS5) / dedicated nodes / SLA / analytics 等の付加価値サービス。

経済学的研究 (Guasoni et al. 2024)

Guasoni らの研究は LSP 集中化の構造を Lightning Network Channels Economics として定量分析。 topology 偏在は 規模の経済から生まれる自然現象であり、競争均衡が "winner-take-most" になりやすいことを示した。これが 監視監視・jamming attack risk・privacy 漏洩のシステミックな影響を持つ。

潜在課題

★★★

Centralization risk

大手 LSP 5 社が大半の inbound traffic を握る "winner-take-most"。Lightning の P2P 性質と緊張関係。

★★

Privacy 漏洩

LSP は user の支払い・受信パターンをすべて観察可能。"non-custodial" だが privacy ではない。

★★

Censorship risk

LSP が特定 user / payment を選別できる。OFAC 対応・規制コンプライアンス強制の余地。

★★

Single point of failure

LSP outage で wallet 利用不能。バックアップ LSP の仕組みは未確立。

§ 8 · Open Problems

LSP / Liquidity 関連の未解決課題

★★★

Multi-LSP redundancy

1 user が複数 LSP に同時接続できる仕組み。1 LSP 障害時のフェイルオーバー。spec / wallet 両側の整備が必要。

★★★

LSP 競争市場の均衡設計

規模の経済による集中化を抑制する mechanism design。reputation system / auction rules の研究機会。

★★

LSP-side privacy preservation

LSP が user の payment pattern を学習しないプロトコル設計（ZKP-based routing 等）。

★★

JIT channel の prepayment probing 対策

探索目的の probe で誤って channel が open される問題。LSPS2 で議論中だが完全解決には至らず。

★★

Splicing × LSP の自動化

ユーザー流動性需要に応じた dynamic splicing の policy 自動化。Eclair が先行実装。

★

Async payment 標準化

受信者オフライン中の支払い受領仕様。Phoenix が先行実装中だが ecosystem-wide 標準は未確立。

研究機会としての LSP

LSP は 経済設計 × プロトコル × プライバシーが交差する領域。Guasoni 2024 系の経済モデル研究、jamming research との接続（LSP-level 統計検知）、 privacy-preserving LSP 設計など、FC / AFT / S&P 級の研究テーマが複数存在する。ユーザーが既存 wiki にある plan_gnn_privacy_defense や jamming hub の研究計画と直接接続する。

§ 9 · Resources & Related Pages

Lightning Service Providerモバイル LN を支えるインフラ層