ライトニングネットワークの成長に伴うアウトバウンドキャパシティ枯渇問題

ルーティング量が増えてきているのは良いことだけど、それに伴いルーティング失敗量も増えている。以前書いたDHレポートでは、ルーティング成功率は5％ほどで、残りはルーティング先の後続ノードのエラー（forward_fail_event）か自身のアウトバウンド資金不足（insuffcient_balance）によるもの。このエラー率の健全な？値はいくつくらいなのだろうか。ネットワークが拡大し、ノード運営者が増えることでさらにこのエラー率が増えるのか（新規参入ノードほどチャネルバランスが悪いため）、ルーティングアルゴリズムの向上で改善されるのか。ルーティングのエラーログを眺めていると、あぁルーティングの機会損失がぁって感じでちょっと悲しくなる。LNを始めると最初に出くわすのがインバウンドキャパシティ問題だが、ノード運用をしていくとアウトバウンドキャパシティ枯渇問題に直面する時がくる。アウトバウンドが枯渇すると以下の図のinsufficient_balanceというエラーが頻出する。これはルーティング依頼は来たが、自チャネルにルーティング可能な資金がないことで起こるエラー。

【LN】 ルーティング手数料の概要と戦略

優良ノードを晒しマース👨🏻‍🏫

Umbrelのお手軽Dropbox自動バックアップ

charge-lnd で fee や max_htlc を自動設定[umbrel 0.5.0以降対応]

AMBOSSアカウントにログインする方法

LNノードの運用益はどれぐらい？パート6

2018年バブル崩壊後に勝ち残った通貨の割合とその特徴

LNノードのバックアップ＆リストア考察

Lightning Networkのノード運用をする場合、特に重要なのがバックアップです。オンチェーン上のビットコインのバックアップは秘密鍵を保管しておくだけで良いですが、LNのノード運用をする場合は少し特殊です。LNノードのバックアップは大きく2つに区別することができます。それは①オンチェーン資金のバックアップと②オフチェーン資金のバックアップです。①のバックアップは秘密鍵の保管をするだけで問題ありません。②のオフチェーン資金のバックアップとは、チャネルのバックアップです。LN上のチャネルは送受信がある度にチャネル状態が更新されていくので、その都度バックアップをとる必要があります。もし古いチャネル状態で相手と通信をすると、不正な状態と見なされ、最悪の場合、資金を失うかもしれません。 data loss protection そのような場合を考慮して、LNの仕様書では data loss protection （DLP）と呼ばれる安全装置が付いています（02-peer-protocol）。これは、もしアリスのチャネル状態が5で、ボブのチャネル状態が6だった場合、アリスのチャネルは古い状態なので、ボブにチャネルを強制閉鎖することを依頼できる仕組みです。この依頼を受けたボブが取れる行動は、(a)最新のチャネル状態6で強制閉鎖するか、(b)古いチャネル状態、例えば自分の残高が多くなるようなチャネル状態まで遡り、そのチャネル状態で強制閉鎖することが考えられます。ボブが(b)の選択をしても、もしアリスが嘘を付いていて最新のチャネル状態までデータを保持していると、ボブはペナルティとして、アリスに全額没収されてしまいます。そのため、ボブは(a)の正直な選択を取ったほうが無難なのです。これが data loss protection と呼ばれる仕組みで、ゲーム理論的な側面があります。この仕様は各LNソフトウェアに実装されています。 またLNDでは、static channel backup（SCB）と呼ばれるチャネル開設がある度に取得するバックアップがあります。これは、最初のチャネル状態だけをバックアップして、リストア時にSCBからチャネル状態を復元しようとするとチャネル状態が古いので、DLPによってチャネルの強制閉鎖を相手に依頼するというものです。このSCBはLNDのみ実装されており、c-lightningやEclair coreには実装されていません。LNのバックアップでは秘密鍵以外にも②のチャネルのバックアップも必要でした。一見するとこのSCBは必須な気がしますが（実際コミュニティでも議論されている<a href="https://github.c

脱Tor！寄り道編～ngrok便利すぎ～

LNDgで自動リバランス

🐇２１のレッスン - ビットコイン・ラビットホールに落ちて学んだコト🕳️もくじ