Closures)の連鎖に関してYuya2023-06-09T03:27:29Z以前の記事でチャネル強制閉鎖がなぜ起きるのかについて書きました。その理由は、HTLCのタイムアウトやソフトウェアのバグなどを挙げていました。メモプール混雑時には強制閉鎖の連鎖が起きてしまうことがあり、その理由を深く考えていませんでした。今回はチャネル強制閉鎖の連鎖に関しての備忘録です。以下の図を例にFCの連鎖について見てみます。AがCへ送金をする際、HTLCがAからB、BからCと追加されます。Cがプリイメジを公開すればHTLCが解消されていきますが、ここでCがオフラインになりました。そのため、B→CのHTLCが解決できずにいます。ここでブロック高が100ブロックに到達しました。HTLCに設定されていたタイムアウトを過ぎたので、HTLCをオンチェーンで解決させるためにB-C間のチャネルを閉鎖します。この時ブロックチェーンに送信されるのがcommitment_txで、このトランザクションのアウトプットにHTLCが構成されていることになります。このHTLCはOffered_htlcと呼ばれるもので、このアウトプットを回収するには、1プリイメジをCが公開するか、2タイムアウトを過ぎればBが回収できます(Offered_htlcなどの構成関係はこちら)。ブロック高はタイムアウトである100ブロックに到達しているので、2の条件でBが回収可能になっています。そこでBは事前に署名済みのHTLC_timeout_txを送信します。このトランザクションが承認されれば、A-B間のHTLCをLN上でキャンセルすることができます。HTLC_timeout_txが未承認のままA-B間のHTLCをキャンセルしてしまうと、Bが損失を被る場合があります。それは、Cがオンラインに戻り、1のプリイメジを公開して資金を回収してしまう場合です。Bによって2のHTLC_timeout_txは送信されていますが、それでもCは手数料を高くするRBFを使い1の条件でHTLCの資金を奪い取ることは可能です。よって、BはHTLC_timeout_txが承認されるまではA-B間のHTLCをキャンセルすることができません。ここで、もしそのHTLC_timeout_txが未承認のまま、ブロック高が140ブロックに到達してしまうと、この度はAがA-B間のHTLCをオンチェーンで解決させるために、A-B間のチャネルを閉鎖します。これがいわゆるチャネル強制閉鎖の連鎖というやつです。この連鎖のための回避策の1つは、以前の記事でも紹介したタイムアウト値(cltv_delta)を大きくすることです。タイムアウトが長くなればHTLC_timeout_txが承認されるまでの猶予時間が長くなります。以下のような回避策も提案されているみたいです。https://github.com/lightningnetwork/lnd/issues/7683上記リンクでは、下流でのHTLCを回収するオンチェーンTXが未承認でも、上流のHTLCをキャンセルさせるというもの。LDKでもこの案について議論させれているみたいです。それでも、やはりHTLCの回収TXが未承認の場合、BはA-B間のHTLCをキャンセルしないほうが安全です。そのようなことも上記のIssueで話されていますが、HTLCの金額が小さい場合はチャネル閉鎖をしないほうが経済的なリスクが少ない場合もあると。上記IssueはLNDのバグが原因で強制閉鎖の連鎖が起きているような雰囲気にもなってきていますね。HTLCをキャンセルさせるかどうかのパターンを表で纏めると良いと思いますが、現状はコードベースを紐解く必要があり、これがチャネル強制閉鎖の連鎖やバグの温床になっている気がします。P1Yuya2023-06-22T22:57:44ZLNDv0.16.3からはoutgoingのHTLCがオンチェーン展開された場合、必ずSweepするようになった。これまではSweepするHTLCが手数料よりも小さい場合は回収していなかったが、その場合IncomingのHTLCをキャンセルしない挙動となり、FCの連鎖を引き起こす。https://github.com/lightningnetwork/lnd/commit/1ba6467c6b6e311e371d9ade2f0502ee48fbee78LNDv0.16.3からはoutgoingのHTLCがオンチェーン展開された場合、必ずSweepするようになった。これまではSweepするHTLCが手数料よりも小さい場合は回収していなかったが、その場合IncomingのHTLCをキャンセルしない挙動となり、FCの連鎖を引き起こす。https://github.com/lightningnetwork/lnd/commit/1ba6467c6b6e311e371d9ade2f0502ee48fbee78Yuya2023-06-15T18:57:09ZHTLC_timeout_txは事前に署名されているから手数料をバンプすることはできないけど、このTXにcommitment_txと同様のアンカーアウトプットを付けておけば、CPFPによる手数料バンプができて上流のHTLCがタイムアウトする前にブロック承認を得て、上流のHTLCをキャンセルできたりしないのかな?とりあえず聞いてみる。https://github.com/lightningdevkit/rust-lightning/issues/2275HTLC_timeout_txは事前に署名されているから手数料をバンプすることはできないけど、このTXにcommitment_txと同様のアンカーアウトプットを付けておけば、CPFPによる手数料バンプができて上流のHTLCがタイムアウトする前にブロック承認を得て、上流のHTLCをキャンセルできたりしないのかな?とりあえず聞いてみる。いうか手数料バンプしたいなら別にアンカーアウトプットなくてもHTLC_timeout_txのアウトプット(これは自身のアドレスだから)に対してCPFPすればいいのか。いうか手数料バンプしたいなら別にアンカーアウトプットなくてもHTLC_timeout_txのアウトプット(これは自身のアドレスだから)に対してCPFPすればいいのか。htlc)が回収されていなくてもキャンセルするとのこと。その条件は、Incomingチャネルのピアとの通信の再接続。htlcがタイムアウトになりそうだったら、そのピアとの通信を再接続すればHTLCをキャンセルでき、チャネル強制閉鎖を防げる。htlc)が回収されていなくてもキャンセルするとのこと。その条件は、Incomingチャネルのピアとの通信の再接続。htlcがタイムアウトになりそうだったら、そのピアとの通信を再接続すればHTLCをキャンセルでき、チャネル強制閉鎖を防げる。article?DeleteCancelErrorClose。