- Campaign
-
Category
チャネル強制閉鎖（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をキャンセルすることができません。 ここで、もしその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をキャンセルさせるかどうかのパターンを表で纏めると良いと思いますが、現状はコードベースを紐解く必要があり、これがチャネル強制閉鎖の連鎖やバグの温床になっている気がします。
チャネルの強制閉鎖 （Force Closure）はなぜ起きるのか？
ペイメントチャネルの二者間がオンラインでいるにもかかわらず強制閉鎖される場合があります。自分のノードだけがこの問題に悩まされているのかなと思いましたが、以下のツイートを見る限り強制閉鎖は頻繁に起きているのが現状のようです。 強制閉鎖される主な理由はHTLCのタイムアウトによるものです。なのでこのタイムアウト時間を長くすることである程度緩和できるかもしれません。以下のリンクのようにLNDはデフォルトのHTLCタイムアウト値（CLTV）が40から80ブロックへ変更されました。 タイムアウト値を長くすることで強制閉鎖を緩和できるかもしれませんが、上記のツイートにあるようにソフトウェアのバグや複数の条件が重なることで起きており、根本原因の究明は難しそうです。 ・・・ 強制閉鎖されると大きな痛手を負う場合があります。以下がその一例です。 手数料高騰している場合 HTLCが追加されていない場合 複数のHTLCが追加されている場合
Package relay がメモプール混雑時のLN送金効率を向上させる
最近のビットコイン手数料の高騰下では、レイヤー２のライトニングでもその影響を受けています。手数料の高騰下ではメモプールが混雑している状態なので、手数料が低い状態でチャネルを閉じようとしてもなかなか承認されません。オンチェーン手数料は常に変動するので、LNではチャネルを閉じるためのトランザクションの手数料もそれに合わせて更新しています。チャネルを閉じる方法は2種類あって、お互いが協調する場合と協調しない場合です。協調的にチャネル閉鎖する場合は、二者間で手数料の交渉を行います。一方、非協調的にチャネル閉鎖する場合は事前に更新された手数料が使われます。この時更新された手数料が適応されるトランザクションをCommitment Txと呼び、二者間の最新の残高がそれぞれアウトプットに割り当てられており署名もされています。このTxは二者間がそれぞれ保存し、どちらかが長時間オフラインになった場合など、協調的にチャネル閉鎖できない場合にブロックチェーンへ送信します。これが非協調的にチャネルを閉じる仕組みです。 LN送金の都度、二者間の残高を更新するためにCommitment Txが更新されますが、それと同時にこのTxの手数料も更新されます。二者間の残高が更新されるわけですが、手数料が増加した場合、送金金額の上限が低くなります。上限値を越えた金額を送金しようとしていた場合、送金が失敗します。具体的には、A - Bのチャネル残高が0.1 - 0.8と手数料0.1の合計1BTCという場合に手数料が2倍に高騰したとします。この時、AがBへ0.1BTC送金しようとすると、手数料を0.2へ更新して、Aの残高から0.1引いてBに0.1足す必要があります。しかし、手数料が0.2になったのでAの残高が0になり送金可能な金額がなくなってしまいます。Commitment Txの手数料を払うのはチャネル開設者で、上記の例はAがチャネル開設者と仮定しています。もしBがAへ0.1BTC送金した場合、0.1 - 0.7と手数料0.2というチャネル残高になります。 上記の理由により手数料の更新ルール`update_fee`を廃除したいという思いがあります。しかしその場合Commitment Txの手数料が低すぎるとブロックに取り込まれません。そのためにAnchorアウトプットと呼ばれるアウトプットがCommitment Txについています。このAnchorアウトプットを使うことでCPFPによる手数料のバンプが可能になります。ただし、CPFPをするには親Tx、この場合Commitment TxがMempoolに存在しないといけません。手数料高騰時にはCommitment TxはMempoolにすら入ることができない場合があります。この問題を解決する仕組みがPackage relayになります。これは関連するトランザクションを1つのパッケージにしてMempoolに送信することができ、そのパッケージ内のトランザクションの平均手数料率が適応されるというものです。これによりCommitment Txの手数料調整を気にする必要がなくなり、低い手数料で非協調的にチャネルを閉じた場合でも、Anchorアウトプットでの手数料バンプで調整することができるようになります。 <iframe style="position: static; visibility: visible; width: 550px; height: 433px; display: block; flex-grow: 1;" id="twitter-widget-1" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" class="" title="Twitter Tweet" src="https://platform.twitter.com/embed/Tweet.html?dnt=true&embedId=twitter-widget-1&features=eyJ0ZndfdGltZWxpbmVfbGlzdCI6eyJidWNrZXQiOltdLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X2ZvbGxvd2VyX2NvdW50X3N1bnNldCI6eyJidWNrZXQiOnRydWUsInZlcnNpb24iOm51bGx9LCJ0ZndfdHdlZXRfZWRpdF9iYWNrZW5kIjp7ImJ1Y2tldCI6Im9uIiwidmVyc2lvbiI6bnVsbH0sInRmd19yZWZzcmNfc2Vzc2lvbiI6eyJidWNrZXQiOiJvbiIsInZlcnNpb24iOm51bGx9LCJ0ZndfZm9zbnJfc29mdF9pbnRlcnZlbnRpb25zX2VuYWJsZWQiOnsiYnVja2V0Ijoib24iLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X21peGVkX21lZGlhXzE1ODk3Ijp7ImJ1Y2tldCI6InRyZW
monacoin-core が relayfee を弄らない単純な理由
つぶやき。ぽえむ。 https://github.com/monacoin-core が ban されました。 GitHub も「こりゃ紛らわしいし酷いわ」とご納得されたようです。めでたしめでたし。 本稿で言う monacoin-core は monacoinproject 版を指します。 Ⓜ️ この ban の間接要因になった「モナコインの手数料は廉価すぎるのは無能の dev がデフォルト値を放置してきたから」疑惑。 ゲーム理論の入門書を斜め読みすれば、愚案であることが明白なのよ。必ず出てくる「囚人のジレンマ」ってやつ。 Spotlight を読みに来るようなｺｲﾅｰな方々は、ゲーム理論もお好きでしょうから、入門書レベルの再解説は省く。 トランザクション手数料の話に適用するならば。 もし採掘者が合理的思考を持ち互いに競合の場合、デフォルトの手数料をどう弄ろうとも、廉価な設定でトランザクションを引き受ける「デフレ競争」が必ず起きる。 それが嫌だと思う採掘者にとっての解決策は、カルテルかトラスト。 これが囚人のジレンマが示すところ。ただでさえ独占的ではとの疑念があるモナコインのマイナーを結託させるインセンティブを与えてどーすんだ? じゃあどーすんだ? 建設的な議論を!!!! 「トランザクション発行者が、喜んで(または巻き込まれて)高額な手数料を支払うような、インセンティブを設計する」これしかない。 ちなみにモナパーティはその一環。 過去を振り返ると、初期のモナコイン系サービスは、ほぼすべてオフチェーンで完結するものだったわけ。tipmona monappy askmona …。ぜんぶオフチェーンだったでしょ? (注: ユーザの利便性を最大限に考えた結果と推察されるので、それらサービスを詰る意図は無い) モナパーティをリリースした真意の一つに「ユーザがトランザクションを発行しないと遊べないサービスインフラを作る」があったのよ。トランザクション発行されないことには手数料云々の議論にすらならない。 だがしかし「モナパーティでは足らん」のは現状見る限りそのとおりで。 最も安直な手として、Taproot Ordinals からの BRC-20 のようなバブルを仕掛けるか、Bitcoin Stamp のような、pruning 困難なゴミをトランザクションに埋め込むのを推奨するか。 だがしかし、いずれにしても持続性無いよね…、と。 「ヲタクのオハジキだ、オモチャだ」っつーても、曲がりなりにもホワイトリストを超えてグリーンリスト入りしている暗号資産で、大きくやらかせば、いろいろ厄介も想定されるわけで。 ぽえむ。
同一HW内でのUmbrelでのノード再インストール＆移行備忘録
上記リンクの通りなのですが、出来心でruncをアップデートしたところ、Umbrelに必要なパッケージが削除されてしまい、解決策が見つからなかったためUmbrelの再インストールとLNDノードの移行を行いました。 将来またやらかしそうな気がするので、以下にノード移行の手順を記録しておきます。今回は同じハードウェア内での移行ですので気が楽です。下記リンク等ちゃんとした解説記事があるので、余程recklessじゃない限りはそちらを参考にしてください。 Umbrelのバージョン：v0.5.3OS：Ubuntu 22.04.2 LTS きちんと計画しての移行であれば全チャネルをdisableしてHTLCがゼロになるまで待った上でUmbrelを停止してからスタートするべきですが、今回は既に停止してしまっているので割愛。 1. まずは最低限必要なデータの避難から・シードフレーズの確認 → Umbrelが生きている場合にはダッシュボードから確認できます。（確認後はちゃんとUmbrelを停止しましょう）・SCPのコピー → bos telegramを使っている場合にはTelegram上で保存されています①~/umbrel/app-data/lightning/data/lnd丸ごと実際に必要なのはlnd.conf, umbrel-lnd.conf, channel.db, wallet.dbなはずですが面倒なので全部コピーしました。②~/umbrel/app-data/bitcoin/data/bitcoinにあるbitcoin.confとumbrel-bitcoin.conf他のUmbrel上のアプリデータ等は特段細かい設定等していないので今回はゼロからインストールしましたが、必要であれば他のファイルもコピー。③
