BOLT 12 + Trampoline + Onion Messages · Phoenix lead

Async Payments
受信者がオフラインのまま Lightning を受け取る

モバイル wallet は 常時オンラインではない(バッテリー / 通信制限 / OS バックグラウンド制限)。従来の Lightning では、受信者がオフライン中の支払いは 失敗する。 Async PaymentsBOLT 12 + Trampoline + Specialized LSP を組み合わせ、受信者が 後でオンラインになるだけで支払いを受け取れる仕組み。 Phoenix が先行実装し、ecosystem-wide な標準化が進行中。

基盤BOLT 12 + Onion Messages + Trampoline
先行実装Phoenix (ACINQ)
標準化BLIP / BOLT 拡張議論中
Hold time典型 24 時間 (configurable)
📴 → 📱
offline → comes online
~24h
typical hold window
Trustless*
*LSP custody minimal
Phoenix
first mainnet
§ 1 · The Problem

モバイル LN の根本的制約 — "always-online" 要件

従来の Lightning は HTLC を受け取る瞬間に受信者がオンラインであることを要求する。理由:

受信失敗のシナリオ

従来の支払い試行(受信者オフライン)

📱 Online
💤 Offline (会議・寝る・電池)
📱 Online
⚠ Payment 試行 → fail

結果

  • 送信者は支払いを retry し続けるか諦める
  • 商品の販売機会喪失(EC・店舗)
  • 給与・寄付・送金の機械化が困難
  • ユーザー体験が CEX に劣る最大の理由
§ 2 · The Approach

「LSP が一時的に hold + 受信者復帰時に forward」モデル

Async Payments の本質は 「LSP が支払いを一時的に hold する」こと。受信者がオンラインになり次第、LSP が forward + settle する。

Async payment timeline

📱
💤 Offline
🛎️ LSP holds
📱 Resume
送金到着
受信者 online → forward

3 つの構成要素の役割

BOLT 12 Offers

静的 invoice endpointを提供。受信者がオフラインでも sender は always pubblicに使える offer を持つ。

Trampoline / LSP

受信者の 常時オンライン代理人。支払いを受け取り、受信者が online になるまで hold。

Onion Messages

LSP が受信者を「起こす」ための 非同期通知 channel(push / webhook 経由含む)。

§ 3 · Trampoline / LSP の役割

「受信者の代わりに hold する常時オン代理人」

Async Payments の中核は Trampoline node(または LSP)がオフライン受信者の代理として支払いを HTLC hold すること。 Hold とは、HTLC を fulfill せずに pending state で保持すること。受信者がオンラインになり preimage を提供したら fulfill する。

Trampoline node に求められる性質

HTLC hold の仕組み

# 従来 (Forward immediately) LSP が HTLC 受信 → preimage forward → settle # 数秒 # Async Payments (Hold) LSP が HTLC 受信 ↓ LSP が HTLC を hold(preimage forward しない) ↓ LSP がモバイルに push 通知(FCM / APNs / webhook) ↓ モバイル wallet wake up ↓ モバイルが preimage を生成(または LSP に保管されたものを渡す) ↓ LSP がモバイルに forward → モバイルが fulfill ↓ LSP が sender 側に preimage 返す → settle 完了 # Hold time: 通常 24h (CLTV expiry の余裕を考慮) # If timeout: LSP が refund (送信者は失敗を学ぶ)
§ 4 · Protocol Flow

Async payment の 7-step フロー

Step 0 / 7
🌐 Sender 🛎️ LSP / Trampoline 📱 Bob (offline → online) ① Bob's static offer (BOLT 12) ② HTLC: 50,000 sats ③ LSP detects Bob is offline → HOLD HTLC #42 pending ④ Push notification (FCM/APNs) ⑤ Bob wakes up 📱 ⑥ HTLC forward + preimage R ⑦ Settle: preimage R back to sender ✅ Payment complete (~minutes to hours after)
Press Play to walk through async payment delivery.
§ 5 · Trust Model & Risks

Async payments の信頼前提

⚠ LSP に対する信頼

  • LSP が 支払い金額を一時的に保持している間は custody risk
  • LSP がオフラインで HTLC が timeoutすると refund
  • LSP が 悪意で hold を続けると support 不能
  • LSP が 支払い情報を観察できる (privacy)

✅ ユーザーが守られる仕組み

  • HTLC の CLTV expiry によって最終的に refund 保証
  • 受信者の 秘密鍵は wallet に保持(custody ではない)
  • LSP が複数の場合、multi-LSP redundancy で SPOF 軽減(議論中)
  • 受信者が定期的に online になれば custody window は短時間

典型的な制約パラメータ

~24h
最大 hold time
~144
CLTV blocks needed
+1-3%
LSP fee premium
FCM/APNs
push 通知 channel

Privacy 課題

LSP は 受信者の支払いパターンをすべて観察できる。BOLT 12 + blinded path で sender からの匿名性は保たれるが、LSP-side では金額・時刻・送信者経路まで知られる。 privacy-preserving async payments は研究機会のひとつ。

§ 6 · Adoption Status

各実装の async payments 対応

Wallet / 実装Async PaymentsBOLT 12Push 通知備考
Phoenix (ACINQ)✓ ProductionFCM/APNs先行実装、reference
Breez部分部分push支援SDK 内で実装中
Mutiny研究中web wallet 制約
OLYMPUS / ZEUSself-hosted LSP
Eclair (lib)✓ (host)N/ALSP 側で hosting
LDK議論中API 設計中
LND議論中部分

標準化の進行

未解決課題

★★★

LSP custody minimization

Hold 中の資金 custody risk を減らす設計(split, multi-LSP, ZKP 等)。

★★

Push 通知の信頼性

FCM/APNs に依存 → Google/Apple 検閲・削除リスク。代替 channel 設計が必要。

★★

Privacy-preserving async

LSP が支払い内容を学習しない設計(blinded ホスティング・ZKP)。研究機会。

★★

標準化の合意形成

Phoenix の de-facto から spec 標準化への移行。LSPS / BOLT 拡張の調整。

§ 7 · Resources

関連

  • 📰 Bitcoin Optech — Async Payments topic page
  • 📜 BOLT 12 — Offers spec (基盤)
  • 🔧 Phoenix Wallet — first production async payments
  • 🔧 OLYMPUS by ZEUS — self-hostable async-capable LSP