Splicing

Splice-inは資金を拠出する側の残高を増やし、splice-outはその残高の一部をチャネル外の出力へ移します。拠出額の増減は全体の容量にも反映されますが、双方の増減が相殺されれば容量は変わらないこともあります。それでも、ビットコイン上でチャネル資金をロックする場所は、必ず別の資金供給出力になります。通常の協調的な閉鎖と、その後の開設は不要です。 [1]

まずチャネルをquiescenceという状態にし、この操作と両立しない更新を一時停止します。開始側がsplice_initを送り、相手側がsplice_ackで応答します。共同で作成する取引には、古い資金供給出力を使用する入力がちょうど一つ、このチャネルに資金を供給する新しい出力がちょうど一つ必要です。それ以外の入力や出力で資金を追加したり引き出したりできます。その後、commitment_signedとtx_signaturesでそれぞれの署名を交換します。 [1]

取引の署名を交換すると、必要とされる承認数に達する前でも支払いを再開できます。そのためノードは、従来の資金構成、新しいsplice、さらにRBFによる置き換え候補に対応するコミットメント状態を並行して保持します。支払いは、有効なすべての候補で成立しなければなりません。接続が切れた場合には進行中の状態を正しく復元する必要があり、最後の取引だけを保存しても不十分です。 [1] [2]

両ノードがoption_spliceの利用を交渉し、取引、手数料率、拠出額に合意する必要があります。相手はtx_abortで提案を拒否できます。双方がsplice_lockedで同じspliceを確定するまでは、新しい更新をすべての有効なcommitment transactionsに反映しなければなりません。相手の残高を一方的に書き換えることはできません。 [1] [3]

Core Lightningはバージョン26.04でSplicingを標準で有効にしました。spliceinとspliceoutのコマンドに加え、二つのチャネル間で資金を移すcross-spliceも導入しています。ただし、相手側ノードのバージョンや対応するチャネルの種類にも左右されます。別々のウォレットに同名の機能があっても、同じことができるとは限らず、互換性も保証されません。 [4]

Splicingでもビットコイン取引を作るため、オンチェーン手数料がかかり、承認や再編成への対応が必要です。例えばEclairには、未承認のspliceの手数料率を引き上げるrbfspliceがあります。チャネルの予備残高、承認済み入力の要件、拠出額やRBF再試行の制限を守り、バックアップの状態にも注意しなければなりません。特別なモードoption_zeroconfでは信頼の前提が変わり、プロトコルはRBFを禁止しています。 [1] [5]

選んだspliceが許容される承認の深さに達し、双方が同じtxidに対するsplice_lockedを交換すると、古い候補や採用されなかった候補を維持する必要がなくなります。変わるのはfunding outpoint、つまり取引の特定の出力を指す参照先です。容量は双方の拠出額の増減の合計で変わります。公開チャネルでは、承認済み取引から決まるshort_channel_idも変わり、双方は新しいannouncement_signaturesを準備できます。 [1]

両ノードの対応状況、channel_id、funding_contribution_satoshisの符号と大きさ、手数料率、入力、出力、予備残高、署名を確認します。RBFの各候補のtxidを追跡してください。完了後はsplice_locked、新しいfunding outpoint、公開チャネルならshort_channel_idも照合します。HTLCの処理が再開したことと、引き出し先の出力が意図したウォレットに属することも確認します。 [2] [1]