同一HW内でのUmbrelでのノード再インストール＆移行備忘録
上記リンクの通りなのですが、出来心でruncをアップデートしたところ、Umbrelに必要なパッケージが削除されてしまい、解決策が見つからなかったためUmbrelの再インストールとLNDノードの移行を行いました。 将来またやらかしそうな気がするので、以下にノード移行の手順を記録しておきます。今回は同じハードウェア内での移行ですので気が楽です。下記リンク等ちゃんとした解説記事があるので、余程recklessじゃない限りはそちらを参考にしてください。 <iframe style="box-shadow: rgba(0, 0, 0, 0.06) 0px 1px 3px;" allowfullscreen="allowfullscreen" allow="autoplay *; encrypted-media *; ch-pr
チャネル強制閉鎖（Force Closures）の連鎖に関して
以前の記事でチャネル強制閉鎖がなぜ起きるのかについて書きました。その理由は、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と呼ばれるもので、このアウトプットを回収するには、①プリイメジをCが公開するか、②タイムアウトを過ぎればBが回収できます（Offered_htlcなどの構成関係はこちら）。すでにブロック高はタイムアウトである100ブロックに到達しているので、②の条件でBが回収可能になっています。そこでBは事前に署名済みのHTLC_timeout_txを送信します。このトランザクションが承認されれば、A-B間のHTLCをLN上でキャンセルすることができます。もしHTLC_timeout_txが未承認のままA-B間のHTLCをキャンセルしてしまうと、Bが損失を被る場合があります。それは、Cがオンラインに戻り、①のプリイメジを公開して資金を回収してしまう場合です。すでにBによって②のHTLC_timeout_txは送信されていますが、それでもCは手数料を高くするRBFを使い①の条件でHTLCの資金を奪い取ることは可能です。よって、BはHTLC_timeout_txが承認されるまではA-B間のHTLCをキャンセルすることができません。 ここで、もしそのHTLCtimeouttxが未承認のまま、ブロック高が140ブロックに到達してしまうと、この度はAがA-B間のHTLCをオンチェーンで解決させるために、A-B間のチャネルを閉鎖します。これがいわゆるチャネル強制
チャネルの強制閉鎖 （Force Closure）はなぜ起きるのか？
ペイメントチャネルの二者間がオンラインでいるにもかかわらず強制閉鎖される場合があります。自分のノードだけがこの問題に悩まされているのかなと思いましたが、以下のツイートを見る限り強制閉鎖は頻繁に起きているのが現状のようです。 強制閉鎖される主な理由はHTLCのタイムアウトによるものです。なのでこのタイムアウト時間を長くすることである程度緩和できるかもしれません。以下のリンクのようにLNDはデフォルトのHTLCタイムアウト値（CLTV）が40から80ブロックへ変更されました。 タイムアウト値を長くすることで強制閉鎖を緩和できるかもしれませんが、上記のツイートにあるようにソフトウェアのバグや複数の条件が重なることで起きており、根本原因の究明は難しそうです。 ・・・</p
ルーティング要求のレート制限で資源効率を向上させる
前回の記事でDiamondhandsノードのルーティングエラー統計について紹介しました。このルーティングエラーの中には自身ではどうにもできないエラーがあり、前回の記事ではエラー番号99がそれであり、DOWNSTREAM_ERROR、後続エラーなどと呼んでいます。そのようなルーティングエラーが多発している場合、そのルーティング要求をしているノード、チャネルに対してレート制限を掛けることが望ましいです。 また、DOWNSTREAM_ERRORを多発させている先行チャネルを特定して、そのチャネルからのルーティング成功率や収益性などを調べてみます。DOWNSTREAM_ERRORが多発していても、ルーティング成功回数や金額が多く収益性が良い場合はレート制限をすると収益が落ちる場合があります。なので、DOWNSTREAM_ERRORを多発させているかつルーティングの収益性が悪いチャネルを特定させて、そのチャネルに対してレート制限をかけてみるのが良さそうです。 以下の画像はルーティングエラーの統計データからある1日を選んで、チャネル別にエラー回数を集計したものになります。
