従来の Lightning channel は open → operate → close という固定的なライフサイクルを持ち、capacity を変更するには毎回 on-chain TX 2 本（close + reopen）と down-time を強いていた。 Splicing はこれを変える: 1 つの on-chain TX で channel state を維持したまま capacity を増減（splice-in / splice-out）できる。 2024–2026 に Eclair / CLN / LDK / Phoenix で実装が成熟し、Lightning UX を最も大きく変えた upgrade のひとつ。
Lightning channel の capacity は open 時点で固定。流入超過で受信不能になっても、追加資金を入れたい場合も、毎回 channel を close → reopen する必要がある。これは：
新 funding TX を作りつつ、旧 commitment TX を新 funding output を spend する形に再構成する。これにより、splice TX が confirm する前から 新 capacity に基づく支払いが可能になる （旧 channel state の security によって safety が保たれる）。
splicing は 3 種類のシナリオを同じプロトコルで実現する。インタラクティブに切り替えて確認できる。
BOLT PR #863 が定義する splice negotiation。quiescence → splice_init → tx_add_input/output → tx_complete → commitment_signed → splice_locked の流れ。
splice TX が confirm されるまでは旧 funding が有効。新 commitment はあらかじめ「新 funding を spend する」形で構築され、splice TX confirm 後に有効化される。
quiescence が解けた後、新 capacity に基づく支払いが即可能（unconfirmed splice TX 上で）。security は新旧 commitment の二重 signing で保たれる。
scid_alias による channel 識別が維持されるため、routing reputation や route hints が継続。
splice TX は 複数の入力・複数の出力を持てる。CLN は multi-channel splice もサポート（複数 channel を同時に splice）。
Splicing は 新 commitment TX への移行を必要とする。その間に新規 HTLC が in-flight だと state inconsistency を起こすため、quiescence（いったん channel を「静粛」状態にする）が必要。 これは stfu（"shut the f* up", 公式メッセージ名）と qack の交換で行う。
Splice TX が低 fee で stuck した場合、RBF (Replace-By-Fee) で fee を上げて再 broadcast できる。 ただし、splice TX には commitment TX が依存しているため、新たな fee で再構築 + 再署名が必要。
| 実装 | Splice-In | Splice-Out | Quiescence | RBF | Multi-channel | Mainnet 投入 |
|---|---|---|---|---|---|---|
| Eclair | ✓ | ✓ | ✓ | ✓ (#2925) | 部分 | 2023 |
| Phoenix | ✓ | ✓ | ✓ | ✓ | — | v2.2 (2024-03) |
| Core Lightning (CLN) | ✓ (#6253) | ✓ | ✓ | 議論中 | ✓ (#8450) | 2023 |
| LDK | ✓ | ✓ (#3979) | ✓ | ✓ (#4427) | — | 2025-08 |
| LND | 議論中 | 議論中 | ✓ (#8270) | — | — | 未投入 |
Channel 自体の capacity を変更する。on-chain output と channel が同一エンティティの所有である必要。
third-party との on-chain ↔ LN swap。Loop / Boltz が provider。channel balance は変わるが capacity は不変。
| シナリオ | 推奨 | 理由 |
|---|---|---|
| routing node の capacity 拡大 | Splicing | cost minimum, scid 維持 |
| mobile wallet が on-chain 受取 | Splice-out (LSP) | JIT channel との組み合わせ |
| On-chain → LN 流動性確保（自分以外と） | Submarine swap | splice には counterparty の同意が必要 |
| Privacy 重視の rebalancing | Submarine swap (Loop) | splice は on-chain footprint を残す |
| 大口の channel 戦略変更 | Splicing | 1 TX で完結 |
2026 時点で LND は quiescence のみ実装。splice-in/out の本格サポートは依然議論中。LN ecosystem の最大シェアを持つ実装の対応が遅れている。
2024-02 に zero-conf channel と v3-transactions の相互作用問題が議論された。新 mempool policy 下での splicing の robust 設計が課題。
CLN が multi-channel splice を実装したが、他実装との interop は未確立。複数 channel を 1 TX で splice する仕様が未標準化。
Eclair #2861 が on-the-fly funding を統合したが、ecosystem 全体で「splice + liquidity market」 の standard pattern が確立していない。
Splicing は on-chain TX に「同じ参加者の resize」を残す。cross-layer deanonymization の研究は splicing pattern まで未拡張。研究機会あり。
「いつ splice すべきか」の意思決定は manual。流動性 utilization・mempool 状況・期待 routing 収益から最適 splice timing を導出する研究は未着手。