同一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
自己紹介
ざっくりした自己紹介です ビットコイン初心者向けサイト「知っとこ!ビットコイン図鑑」を制作しています知っとこ!ビットコイン図鑑 仮想通貨のアフィエイトメディアでたくさん記事を書いてきましたが全部仕事切られたのでもう仮想通貨じゃなくて別ジャンルのライターになろうかなぁとかライター以外に転向するかとか考え中です 今から新しく仮想通貨メディアに入るとなるとアルトコインを推奨する記事を書いたりこれはあかんやろ的なサービスを推奨する記事を書いたりしないといけないのが目に見えてるのでなんかやだ(わがまま もうちょっと真面目なプロフィールを見たい方はnoteの方へお願いしますライター初期の頃に作って最近いろいろ書き直しましたNoteでは商材屋批判を書いていこうと思ってましたが今はビットコイン図鑑が楽しいんで2記事で止めましたhttps://note.com/sigeru_minami/n/n5b39c4cc1e1b 最近お世話になっているのはリバタリマンさんのスペースですよく参加させてもらっていますLibertariman Radio - リバタリマン・ラジオ#47 ビットコインの生みの親はサトシ・ナカモト、でもWe are all Satoshi 2024-02-02 この回はサトシ・ナカモトについてクレイグ・ライト/サトシの日本名について/ハル・フィニー(+ムーブメントの話)/We are all Satoshi/金子勇/サトシの名言 などの話を聞きました(18:45くらいから参加しています) 反省会DAOのDiscordもお世話になっていますビットコイン図鑑という部屋に出没しますちょっとリンクの仕組み(期限切れとか)が分からないのでご興味ある方はコージさんの動画から飛んでください一応コージさんのツイートにあったリンクを貼っておきます<a dir="ltr" href="https://t.co/GeduQ1zvkT" rel="noopener noreferrer nofollow" target="_blank" role="link" class="css-1qaijid r-bcqeeo r-qvutc0 r
チャネル強制閉鎖(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