LNのSplicingについて
この画像がわかりやすくすべてを表している
https://scrapbox.io/files/686270ec51f0c5baf4dae69f.png
Splicingとは？
既存のチャネルの残高を「途中で再構成」し、資金の追加・取り出しを可能にする技術
従来は「チャネルを閉じて新規オープン」しかできなかったが、Splicingにより1回のオンチェーンtxでサイズ変更できる
「Splice In（チャネル容量増加）」と「Splice Out（チャネルから資金引き出し）」の双方が可能
💡 なぜ重要？
チャネル開閉の手間とコストが半減
モバイル・ウォレットでの「1つの残高UX」を実現
LSPやルーティングノードの資金効率化 ・動的な liquidity 管理が可能
⚙ 技術的フロー
STFUモードでチャネル状態を一時停止
splice → splice_ack → Texas interactive construction プロトコルで新txに追加入力と出力を交渉
署名 → オンチェーンにブロードキャスト、6確認後に旧チャネル状態を廃止
解説・実行動画
https://www.youtube.com/watch?v=SqG6yvIBjfs
------------------------------
Splicing Explained（スプライシング解説）
Splicing の本質はシンプルです。それは「Lightning チャネルのサイズを変更する能力」です。しかし時間の経過とともに、チャネルをサイズ変更できることで、当初は直感的に明らかでなかった多くの追加的な利点があることがわかってきました。そしてこれは Lightning の実用性を根本的に高めることになります。
Splicing の利点は大きく2つ
ユーザー側の体験改善
バックエンドでの流動性最適化
ユーザー側の改善
最近では多くのビットコインウォレットアプリがありますが、開発者は「ビットコイン（オンチェーン）にするか Lightning にするか」で悩みます。
多くのアプリはどちらか一方にしますが、野心的なアプリは両方に対応します。これは理論上は最適ですが、「オンチェーン残高と Lightning 残高の2つを持つ」という問題を引き起こします。
これは初心者には非常に混乱を招くもので、ビットコイン上級者でなければ使いづらいです。
この"2つの残高問題"は UI デザイン上の問題だけでなく、実際に2つのモードが根本的に異なり、統合しようとすると手数料や遅延という新たな課題が発生します。
Splicing により、オンチェーンと Lightning を低コストで相互運用できるようになり、「1つの残高で完結するウォレット」が実現可能になります。
バックエンドの流動性改善
Lightning は多数の「小さな銀行（ミニバンク）」のネットワークとして動作しています。これらは「自身の範囲内での送金ルーティング」という1つのサービスだけを提供します。
中央銀行的なモデルとは異なり、Lightning は「誰でも銀行になれる」という考え方で分散ネットワークを形成します。
ミニバンクは支払い経路上でビットコインを事前に保有しておく必要があり、通常 100 以上のアカウントを持ち、絶えず資金を移動させています。しかしこれはコスト・予測難度が高く、また未使用資金（リザーブ）を持つ必要もあります。
Splicing によって、チャネルの閉鎖や再開設のコスト、リザーブの必要性が解消され、運営コストと資金効率が劇的に改善します。ネットワーク全体もより頑健になり、中央流動性プロバイダへの依存も減少します。
Splicing の技術的概要（高レベル）
https://scrapbox.io/files/686266513bc3adbb529d1eb1.png
Splicing とは、Lightning チャネルの資金を新しい UTXO に移すプロセスです。理論上は 2-of-2 マルチシグの新しい場所への再署名だけで済みますが、信頼を前提としない環境では簡単ではありません。
まず、現在の commitment state が作業中に変化しないように、一時的にチャネル状態を静止させる STFU（SomeThing Fundamental is Underway）モードに入ります。
その後、Interactive Transaction Protocol を使って、各ノードが順にインプットやアウトプットを追加していきます。必要に応じて他チャネルのオープンや複数のスプライスもまとめて行えます。
合意が取れたら双方が署名し、ブロードキャスト後に6確認を待って新しい状態を有効化し、旧状態は破棄されます。
実装に関する考慮点
チャネル状態を "新規として扱う" か "既存状態に上書きする" かを決定する必要があります。
Dual channel 状態の管理 vs Unified 状態の管理にはそれぞれメリット・デメリットがあります。
interactive tx module の共通化（dual fundingと兼用）
STFU 管理の状態遷移・競合解決（同時にスプライスが走った場合の衝突）
PSBTベースのパラメータと相対的なチャネル容量の調整
今後の展望
さらなる実装例や STFU の改善提案が登場予定
実装支援が必要な場合は Dusty Daemon（提案者）に問い合わせを
ビデオ解説も複数公開されています
--------------------------------------------